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 Tue, 29 Jul 2003 13:16:34 GMT
Hi all,

> [..Snip..]
> >> I suspect that a cast-to-get-alternate-behaviour is the right way
> >>forward.
> >
> >+1
> >
> >>Which way should be the default way ? That depends on what other
> >>peoples assumptions of what the correct behaviour is. Probably, the
> >>behaviour isin correct and therefore the old behaviour should be
> >>behind a cast.
> >
> >+1, name of the new "hidden" method?
> How about flush :
> /** Calling <code>flush</code> flushes persistent object modifications
>   * made within the ODMG transaction since the last checkpoint to the
> underlying database
>   * transaction, but does not commit the database transaction. The
> transaction
>   * retains all locks it held on those objects at the time the flush
> invoked.<br/>
>   * flush is very similair to <code>checkpoint</code>, save that
>   * <b>does</b> commit the database transaction.<p/>
>   * Note : this method is <b>not</b> part of the ODMG Transaction
>   */
> public void flush(){
>  ...
> }

I want to introduce a new interface merge all
proprietary public methods used in TransactionImpl

public interface TransactionExt extends Transaction, HasBroker
public void markDelete(Object anObject);
public void markDirty(Object anObject);
public void flush();

Better cast to interface, because in future we will
replace current implementation by a new one using
OTM layer.

What do you think?


> Cheers,
> Charles.
> This email and any attachments are strictly confidential and are
> solely for the addressee. If you are not the intended recipient you
> not disclose, forward, copy or take any action in reliance on this
> or its attachments. If you have received this email in error please
> the sender as soon as possible and delete it from your computer
> Any views or opinions presented are solely those of the author and do
> necessarily reflect those of HPD Software Limited or its affiliates.
>  At present the integrity of email across the internet cannot be
> and messages sent via this medium are potentially at risk.  All
> is excluded to the extent permitted by law for any claims arising as a
> 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

View raw message