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]
