Re: Antwort: Re: ObjectEnvelope’s modificat ion detection mechanism – “abort() after fl ush()”

[Armin Waibel]

Hi Mario,

Mario Curcija wrote:
Hi Armin,

        Thanks for replying. We are actually striving to upgrade from 
1.0.1 to 1.0.4 (hopefully later to 1.0.5 as well). As I see ODMG API is 
not very popular among ojb-users. Today I checked Jira Issues tracking 
system again looking for a bug report regarding our problem, but I wasn’t 
able to find anything similar. Should I open one? 

Yes! This will remind me to fix this issue (and to note in the release 
notes) and you can comment my solution/ reopen the issue if necessary.


I think you’ll have to renounce “reuse” strategy if you are concerned 
about performance in this case (after introduction of “initialImage”). 
Finally only “flush()” calls are affected by this problem. 

I try to avoid an additional image object. Locally I introduce an 
enumeration class WriteMode with three modes (commit, checkpoint, flush) 
and class ObjectEnvelope remember the current and last WriteMode. If now 
tx.commit() is called and an error occur OJB can check for the last 
WriteMode. If the last WriteMode is WriteMode.FLUSH OJB will evict the 
associated persistent object from the cache (this fix will the issue 
with performance impact). Think this is very similar to your suggestion 
but with WriteMode instances instead of an additional image object.

Now the tests
- testTransactionFlush()
- testTransactionFlush_2()
pass using ObjectCacheDefaultImpl (with autoSync=false).

Hope I find the time to check in the changes and build a new 1.0.5RC 
during the next week.

regards,
Armin


Best regards, 
Mario Curcija


Armin Waibel <[EMAIL PROTECTED]> schrieb am 21.03.2008 03:42:13:

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



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]