Hi ojb-users, yesterday, I ran into a problem during testing against 1.0.5rc1. The following two tests:
- testTransactionFlush() and - testTransactionFlush_2() (both coming from org.apache.ojb.odmg.ODMGRollbackTest) are failing when ObjectCacheDefaultImpl (with autoSync=false) is used as object-cache implementation instead of default one (“twoLevel”). Both tests are doing following: - persisting previously non-persisted objects by invoking Transaction.lock(Object, int) and calling TransactionExt.flush() afterwards, - performing Transaction.abort() and at last, - checking for existence of used objects (in DB/Cache) via org.apache.ojb.broker.query.QueryByIdentity expecting not to find them. In these tests objects were not evicted from cache as expected (on abort() call). I was hoping that problem was in usage of ObjectCacheSoftImpl as cache implementation but it turned out that that ObjectEnvelope’s modification detection mechanism doesn’t correctly supports “abort() after flush()” since ObjectEnvelope’s internal images (beforeImage and currentImage) are reused during subsequent flush() calls (please check following two methods: ObjectEnvelope.cleanup and ObjectEnvelope.hasChanged). We are experimenting with a workaround that makes use of an additional “initialImage” (reference to first beforeImage), that let's the hasChanged method detect changes with respect to “initialImage” correctly in the case when abort() is invoked after flush(). However, we are not sure, whether this might have other implications. On the other hand, the only reason why those two test-cases are running fine with default “twoLevel” as object-cache is while it implements PBStateListener interface and reacts on beforeRollback(PBStateEvent) by clearing session cache(thus removing newly created objects). Best regards, Mario Curcija
