Hi there. So first the stats:
hibernate 3
jboss 4.0.2
postgresql 8.1
java1.5

I switched my transaction management to CMT a few months ago, and since then we've had this recurring problem (maybe once a day) where the cache becomes "corrupt" and needs to be flushed to continue working. By corrupt I mean this: object A has a collection of B's which it caches. A user loads the page and for some reason A has B1, B2, and B3 in its collection of B's (from the cache). However B3 has not been loaded and it needs to go to the database to load this object. This object does not actually exist in the database so I get an error which I pasted at the bottom of this post.

One explanation I could think of was if I explicitly delete a B3 but do not remove it from A's collection, but i do not perform any deletes of B anywhere in the code.

The other thought was perhaps I add B3 to A's collection, and it updates the collection in the cache, then the transaction rolls back or there is unlucky timing where B3 is not saved to the database but a concurrent transaction tries accessing A. However I've written several test cases and cannot reproduce it, so it either must be timed perfectly at some stage inside of code beyond my control, or there is another explanation.

What I'm asking for mostly is for someone to give me any suggestions in narrowing down the problem to help debug it, or perhaps ways of working around to avoid the symptom.

Oh yeah, one more thing, I do have some Session.refresh(A) calls in the code - might that cause issues with cache? Like i said i cannot create a test case that fails outside of production.

Thanks to anyone who can offer suggestions.



====STACK TRACE: ==================

(B = UserVerificationStatus, and the call is Session.load(A.class, pkey)

org.hibernate.ObjectNotFoundException: No row with the given identifier exists:
[com.studentuniverse.verification.persistent.UserVerificationStatus#1092534]
at org.hibernate.ObjectNotFoundException.throwIfNull(ObjectNotFoundExcep
tion.java:27)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEven
tListener.java:118)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultL
oadEventListener.java:151)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEv
entListener.java:79)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:641)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:257)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:160)
at org.hibernate.collection.PersistentSet.initializeFromCache(Persistent
Set.java:96)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCac
heEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.init
ializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:126)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onIn
itializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:
1412)
at org.hibernate.collection.AbstractPersistentCollection.forceInitializa
tion(AbstractPersistentCollection.java:271)
at org.hibernate.engine.PersistenceContext.initializeNonLazyCollections(
PersistenceContext.java:796)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Lo
ader.java:215)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1311)
at org.hibernate.loader.entity.EntityLoader.load(EntityLoader.java:116)
at org.hibernate.loader.entity.EntityLoader.load(EntityLoader.java:101)
at org.hibernate.persister.entity.BasicEntityPersister.load(BasicEntityP
ersister.java:2461)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(D
efaultLoadEventListener.java:350)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEv
entListener.java:331)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEven
tListener.java:113)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultL
oadEventListener.java:151)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEv
entListener.java:79)
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:589)
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:582)
at com.studentuniverse.framework.dao.BaseDAO.load(BaseDAO.java:135)

Probably it was deleted outside your code.

Well I should have mentioned that my app is the only one with write access to the database, so it is definitely happening inside this code. I wonder why the object B would not be in the _cache_ at the very least though, since it is cached and its existance is also cached, and all objects share the same cacheing parameters (eternal=true).

I would be kind of nice to enable sql output, but to also see parameters (accepting any performance cost).

Then also enable a logging mode that faciliated greping all single instance modify actions etc.. on the instance id. So it would emit a log entry "#delete(com.company.MyObj#12345)". This way you could collect the information needed to rule things out for sure.