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 the session is flushed , then after flushing, the collection is initialized, it will contain the
{code}
s = openSession();
+ txn = s uncommitted entity . beginTransaction In the process, the collection ( including the uncommitted entity ) ;
+ item = (Item) s is put in the collection cache . get( Item.class If the transaction rolls back , item 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 . getId() );
+ assertFalse( Hibernate
I've added a test marked FailureExpected that reproduces this:
org . isInitialized( item hibernate . getBagOfItems() ) );
+ // Add an element to item test . bagOfItems (a bag); it will not initialize the bag cache .
+ item infinispan . addItemToBag( itemElement );
+ assertFalse( Hibernate functional . isInitialized( item BasicTransactionalTestCase . getBagOfItems testAddNewOneToManyElementNoInitFlushInitLeaveCacheConsistent () ) );
+ s . persist( itemElement );
+ s.flush
The same will happen for an uninitialized Set if ( only ) ;
+ // Now initialize the collection; it will contain many-to-one side of the association is initialized, the session is flushed, the Set is initialized (containing the uncommitted itemElement data), and the transaction is rolled back .
+ Hibernate However, this does not comply with the JPA spec . initialize( item.getBagOfItems() );
+ setRollbackOnlyTx();
{code}
|
