BTW if it's helpful, the entity and the two records in the collection were created in three separate database transactions, and this is all running on a single node.
One last thought... is it possible that this is occurring since I haven't set up the transaction manager lookup, so the cache update is occurring later than the DB update, even though this is on a single machine?
Brian, any chance you could try replicating this issue again and send me logs with TRACE on org.hibernate and org.infinispan?
Is the primary key of these entities a custom one? Or is it just an integer for example? The key does need to implement equals() and hashCode() but the entity or collection itself now.
Even if the cache update was happening so much later, it'd eventually happen but I don't think this is to due with lack of transaction manager unless you saw some exceptions.
I'll turn on logging and see if I can reproduce the issue.
Regarding the key, it is just a Long, so I'll continue without any equals/hashCode on my entities/collections.
Lastly, for a single node "cluster", should the 2nd level cache on the local machine get updated before org.hibernate.Session.close() returns, or afterwards (and in a separate thread)? In other words: I have a unit test running on a single machine in a single node cluster, and I add some rows to an existing collection and then close the Hibernate session, open a new one, and check the collection contents -- should the local 2nd level cache have been updated before the first close() returns, or does the 2nd level cache provider do the local cache update in a separate thread?
Brian, are your operations in the session wrapped around any transactional work? IOW, do you use any of the patterns indicated in https://www.hibernate.org/42.html ?
Based on past discussions, I suppose that, if anything, you might use the "Transaction demarcation with plain JDBC" pattern?
I've run some quick tests and without any transactions (iow, not using any of the patterns in that page) the 2nd level cache does not seem to get updated and neither my hypersonic database.
Then again, we only support transactional or read-only cache mode for Infinispan 2nd level cache, so if you wanna modify the contents of the database and them to get propagated to 2nd level cache, you need to use transactions one way or the other. So far, all our tests work using the JTA pattern. I've just run a quick tests with JDBC transaction and the 2nd level cache was being updated.
Yes, I'm using transaction demarcation using plain JDBC. In other words I'm doing:
1) s = SessionFactory.openSession();
2) tx = s.beginTransaction();
3) Create/save/change objects
I also have all of my entities and collections set to cache usage=transactional. The cache update issue I'm noticing appears to only be with collections, not with top-level entities, and it is intermittent.
I'll hopefully have a log soon that you can look at that may be helfpul.