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]
