2nd Level Cache inconsistencies/duplicates

[bjve]

I noticed some inconsistencies between the DB and 2nd level cache that may shed some light on the issue I reported earlier when setting Lifespan, although now I'm seeing it without any custom Lifespan settings.

I'm noticing that after enabling collection caching for some of my collections that two things are happening (intermittently):
* Data in a collection that is getting written through to the database is not getting updated in the 2nd level cache. These are all new record creations, not record updates. In my case, a collection in the database contains two records but when I get the collection in code, the collection only contains one object.
* The 2nd level cache looks like it has multiple CollectionCacheEntry objects for the same object ID. I found these duplicate entries looking in regionFactory.caches. For example, I have an entity with ID 2971 with a collection that in the database has two records, with ID 11181 and 11182. In the in-memory cache, there's a CacheKey for entity 2971 and it contains two entries, but both with ID 11181. I saw several other collection caches that also contained multiple entries for objects with the same ID.

Possibly related: Is it necessary to implement equals and hashCode on my entities for the Infinispan 2nd level cache to work correctly? I don't implement them currently since I never refer to my objects outside of a live session.

Thanks,
Brian

[bjve]

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.

[bjve]

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?

[galder.zamarreno]

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.

[galder.zamarreno]

If you need help with enabling logging, here's a link that might help:
http://www.jboss.org/community/wiki/infinispantechnicalfaqs/#How_can_I_enable_logging

[bjve]

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?

[galder.zamarreno]

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.

[bjve]

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
4) tx.commit()
5) s.close()

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.