Re: ObjectEnvelope’s modification detect ion mechanism – “abort() after flush()”

Hi Mario,

Mario Curcija wrote:
> Hi ojb-users, 
> 
> yesterday, I ran into a problem during testing against 1.0.5rc1. 

Many thanks for testing RC1!


> 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). 
> 

You are absolutely right! It's a bug. Thanks for the detailed 
description (make it easy to reproduce the issue).


> 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. 

Let me think about this (for a day or two). Another Image instance and 
detection of changes could have an impact on memory consumption and 
performance.

regards,
Armin

> 
> 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).