The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience. (1) [Avatar] Offline
At page 257 it is stated that 'With read-committed isolation, the same Item might show up twice while your procedure runs!'
How might this happen as when the item already exists in the context cache, newer data is ignored (see page 219, 'This cache also affects results of arbitrary queries, executed for example with the javax.persistence.Query API. Hibernate reads the SQL result set of a query and transforms it into entity instances. This process first tries to resolve every entity instance in the persistence context by identifier lookup. Only if an instance with the same identifier value can't be found in the current persistence context does Hibernate read the rest of the data from the result set row. Hibernate will ignore any potentially newer data in the result set, due to read-committed transaction isolation at the database level, if the entity instance is already present in the persistence context.'.
Christian Bauer (56) [Avatar] Offline
Re: Transaction, manual Version checkend
I've added a note to the book:

FAQ: Why does the persistence context cache not prevent this problem?

The "get all items in a particular category" query returns item data in a ResultSet. Hibernate then looks at the primary key value in this data, and first tries to resolve the rest of the details of each Item in the persistence context cacheĀ—it checks if an Item instance has already been loaded with that identifier. This cache however doesn't help in our example procedure: If a concurrent transaction moved an item to another category, that item might be returned several times in different ResultSets. Hibernate will perform its persistence context lookup and say "Oh, I've already loaded that Item instance before, let's use what we already have in memory". Hibernate isn't even aware that the category assigned to the item changed, or that the item appeared again in a different result. Hence this is a case where the repeatable read feature of the persistence context hides concurrently committed data. You need to manually check the versions to find out if the data changed while you were expecting it not to change.