We're updating the issue view to help you get more done. 

Uncommitted data can remain in transactional collection cache after rollback if collection is initialized after flush

Description

This issue shows up using infinispan with transactional caching strategy with a bidirectional one-to-many/many-to-one association that is a bag. It may also affect a unidirectional or many-to-many association, but I have not tested that.

If a new entity element is added to an uninitialized bag, the bag remains uninitialized (as expected). If, after flushing, the collection is initialized, it will contain the uncommitted entity. In the process, the collection (including the uncommitted entity) is put in the collection cache. If the transaction rolls back, then, in a later transaction when that collection is initialized from the cache, an ObjectNotFoundException will be thrown when trying to assemble the uncommitted entity.

I've added a test marked FailureExpected that reproduces this:
org.hibernate.test.cache.infinispan.functional.BasicTransactionalTestCase.testAddNewOneToManyElementNoInitFlushInitLeaveCacheConsistent().

The same will happen for an uninitialized Set if (only) the many-to-one side of the association is initialized, the session is flushed, the Set is initialized (containing the uncommitted data), and the transaction is rolled back. However, this does not comply with the JPA spec.

Environment

None

Status

Assignee

Galder Zamarreno

Reporter

Gail Badner

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

backportDecision

None

Affects versions

4.3.5

Priority

Major