StaleObjectStateExceptions raising outside flush context.

Description

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.

Environment

Hibernate4.3.9, SQLServer2008, EHCache as 2LCache

Assignee

Gail Badner

Reporter

Guenther Demetz

Fix versions

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

Affirmative

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Critical
Configure