You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Mario Curcija <Ma...@lex-com.net> on 2008/04/01 09:19:12 UTC
Antwort: Re: ObjectEnvelope’s modification detection mechanism – “abort() after flush()”
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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
Re: Antwort: Re: ObjectEnvelope’s modification detection mechanism – “abort() after flush()”
Posted by Armin Waibel <ar...@apache.org>.
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 <ar...@apache.org> 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: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org