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