Uncommitted data can remain in transactional collection cache after rollback if collection is initialized after flush
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:
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.
Closing resolved issued in preparation for releasing 4.3.6.
Fixed in master, 4.3, and 4.2.
I added at test that confirmed that a colllection that uses a property-ref does not get cached if it contains a new entity.