db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Armin Waibel" <ar...@code-au-lait.de>
Subject Re: checkpoint problem
Date Mon, 28 Jul 2003 16:23:57 GMT
Hi Charles,

----- Original Message -----
From: "Charles Anthony" <charles.anthony@hpdsoftware.com>
To: "'OJB Developers List'" <ojb-dev@db.apache.org>
Sent: Monday, July 28, 2003 5:46 PM
Subject: RE: checkpoint problem


> Hi;
>
> I'm not 100% sure, but my understanding was that
Transaction.checkPoint()
> should flush all changes to the transaction to the database, but *not*
> commit the underlying database transaction; this then allows queries
in the
> same ODMG transaction to access the updated data, but not other
database
> transactions. It would also allow later code to "rollback" to before
the
> checkpoint.
>

This was my understanding too, but after reading odmg-docs published
by POET I thought Jeremy was right.

<snip poet docu>

Checkpoints
The Transaction class also provides a checkpoint mechanism. Checkpoints
are interim commit operations that do not end the transaction. These can
be
performed at any time while a transaction is open. When you call the
checkpoint() method of the transaction, the modified objects associated
with
the transaction are written to the database, but they keep their locks.
You can
think of the checkpoint as equivalent to calling commit() followed
immediately by begin().
....
The transaction is ended by calling abort(). The changes that were made
to
the objects prior to calling checkpoint() have already been written.
Only
the changes made after the checkpoint() call are lost.

</snip>

> I certainly have written code that depends upon the above behaviour.
>
> Looking at the API Javadoc for Transaction.checkPoint(), I accept this
is
> not necessarily correct - but either way is a reasonable
interpretation of
> the spec.
>
> If we stick with the patched version, is there another way I keep
achieve
> the above behaviour (tried to flesh it out a bit below)?
>
> Psuedo code :
>
> tx.begin()
> tx.lock(anObject, WRITE)
> tx.lock(anotherObject, WRITE)
> // lots of other lock-for-writes
> tx.checkPoint()
> executeQuery(); (This querys the tables for instances of classes that
> anObject is an instanceOf i.e. anObject may be returned by the query)
> // lots of other queris and or writes
> file://OK - we need to rollback, as there is a logical error
> tx.abort(); // This should roll back writes/updates back to the
tx.begin
>

This is exactly the scenario I had in my mind for using
checkpoint (old version).
What are the alternatives:

- rollback to old version
- introduce new non odmg-standard method in
TransactionImpl (user needs cast). Either this method represents
behaviour like Jeremy mean or like the old version of checkpoint()
- make this behaviour configurable in properties

I'm stumped. Don't know what's the 'right' solution.
what do you think?

regards,
Armin


> Cheers,
>
> Charles
>
>
> >-----Original Message-----
> >From: Armin Waibel [mailto:armin@code-au-lait.de]
> >Sent: 28 July 2003 16:28
> >To: OJB Developers List
> >Subject: Re: checkpoint problem
> >
> >
> >Hi Jeremy,
> >
> >I add your patch to CVS. Thanks!
> >
> >regards,
> >Armin
> >
> >----- Original Message -----
> >From: "Jeremy Wilkerson" <jjwilkerson@ubtanet.com>
> >To: <ojb-dev@db.apache.org>
> >Sent: Thursday, July 24, 2003 2:57 PM
> >Subject: checkpoint problem
> >
> >
> >> I'm using the ODMG API of OJB 1.0.rc3 with MySQL. When I call
> >> checkpoint() on a Transaction, the underlying database transaction
> >isn't
> >> being committed. I added the following to
> >TransactionImpl.checkpoint(),
> >> right after doCommitOnObjects();
> >>
> >>            if (getBroker().isInTransaction())
> >>                getBroker().commitTransaction();
> >>
> >> It seems to work.  This likely isn't the best solution, as I'm not
> >very
> >> familiar with the OJB code.  If this problem has already been fixed
> >> somewhere else, someone please tell me where to look in the CVS
tree.
> >>
> >>
>
>> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> >> For additional commands, e-mail: ojb-dev-help@db.apache.org
> >>
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> >For additional commands, e-mail: ojb-dev-help@db.apache.org
> >
>
>
> This email and any attachments are strictly confidential and are
intended
> solely for the addressee. If you are not the intended recipient you
must
> not disclose, forward, copy or take any action in reliance on this
message
> or its attachments. If you have received this email in error please
notify
> the sender as soon as possible and delete it from your computer
systems.
> Any views or opinions presented are solely those of the author and do
not
> necessarily reflect those of HPD Software Limited or its affiliates.
>
>  At present the integrity of email across the internet cannot be
guaranteed
> and messages sent via this medium are potentially at risk.  All
liability
> is excluded to the extent permitted by law for any claims arising as a
re-
> sult of the use of this medium to transmit information by or to
> HPD Software Limited or its affiliates.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message