Until Hibernate4.2 StaleObjectStateExceptions were raised exclusively on flush calls. Now with Hibernate4.3.9 we have StaleObjectStateExceptions too on read calls (CollectionInitialize), which seems unexpected behavior since Hibernate should maintain his repeatable-read behavior. Here a stacktrace:

org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : com.wuerth.phoenix.Cis.bc.persistent.jpa.BusinessCardPeer#711
at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.checkVersion(EntityReferenceInitializerImpl.java:499)
at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.checkVersion(EntityReferenceInitializerImpl.java:453)
at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.hydrateEntityState(EntityReferenceInitializerImpl.java:209)
at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:107)
at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:129)
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138)
at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
at org.hibernate.loader.collection.plan.AbstractLoadPlanBasedCollectionInitializer.initialize(AbstractLoadPlanBasedCollectionInitializer.java:100)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:693)
at org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:92)
at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1933)
at org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork(AbstractPersistentCollection.java:558)
at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:260)
at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:554)
at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:142)
at org.hibernate.collection.internal.PersistentSet.toArray(PersistentSet.java:187)
at java.util.Collections$UnmodifiableCollection.toArray(Collections.java:1033)
at java.util.ArrayList.<init>(ArrayList.java:177)
at com.wuerth.phoenix.cis.tasks.tools.monitors.creditlimitmonitor.CreditLimitMonitorTableModel.getValueAt(CreditLimitMonitorTableModel.java:226)

As you can see from the stack we are clearly outside any flush context here,
how is that possible?

Until now I was not able to reproduce it in a testcase...sorry.