the pattern that Victor describes is called 'transactional saga'. Any C
programmer is somewhat familiar with it. It's used whenever a LOGICAL
transaction must span thru multiple PHYSICAL transactions. It's based on the
concept of equalizing transactions, this is, transactions that somehow
restore the integrity of the critical business state:
T1----T2-----T3
/ /
/ /
/ /
/ /
R1----R2
If T2 fails, then R1(rollback transaction 1) is called, if T3 fails, then R2
is called first, then R1 is called. There's no need (in this general case)
to have a R3, because T3 is the last in the saga.
One more thing on Rollback transactions, it's not needed that it completely
undo the original TX.
Example
T1 credits $100 in an account ID 001, by inserting a record with an amount
of +100 and an account ID of 001 into the AccountMovement table.
R1 may:
1. erase the record.
2. debit $100 by inserting a record with an amount of -100 and an account ID
of 001 into the AccountMovement table.
This pattern is commonly used whenever dissimilar systems are involved and
they do not cooperate with each other, say, T1 is run on SAP DB, T2 is a
MySQL DB and T3 is SQL Server. Because SQL Server nor MySQL don't support
2PC, it must implement the logical transaction this way.
C programmers are used to this pattern(pseudo code):
void * m = malloc(1024);
void * n = malloc(1024);
void * o = malloc(1024);
int st=-1;
if (!m)
st=0;
if (!n)
st=1;
if (!o)
st=2;
if (st < 0)
{
//sign up for total cleaning
st=3;
//all ok,do my job
//end of rutine
}
switch(st)
{
case 3:
free(o);
case 2:
free(n);
case 1:
free(m);
}
return;
notice there are no break's
HTH
JP
> -----Original Message-----
> From: Robert Nicholson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 4:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Trip planning problem... transactoin attributes?
>
>
> This is a little vague.
>
> Given that the scope of the transaction will be during the
> method call how
> can you undo the effects in their own methods?
>
> I have
>
> purchaseFirstLeg()
> purchaseSecondLeg()
> purchaseThirdLeg()
>
> returning a system exception from any of these if they are
> TX_REQUIRES_NEW
> will rollback it's own transction so what would these
> "cancel" methods do?
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Victor Langelo
> > Sent: Wednesday, March 07, 2001 10:07 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Trip planning problem... transactoin attributes?
> >
> >
> > Robert,
> >
> > Since EJB supports only flat transactions, it will not handle
> > this very easily.
> > You would need nested transactions to support rolling back a
> > portion of work
> > without cancelling the entire operation.
> >
> > You can achieve the same effect by creating three additional
> > methods which would
> > undo the effect of the purchase methods.
> >
> > cancelFirstLeg();
> > cancelSecondLeg();
> > cancelThirdLeg();
> >
> > You then have two options. Put planTrip in a transaction or put
> > each leg in it's
> > own transaction. How you handle the transactions depends on what
> > interaction is
> > desired on other processes.
> >
> > --Victor
> >
> > Robert Nicholson wrote:
> >
> > > Suppose you have to plan a world trip (Ed Romans Trip Planning
> > example) and
> > > there are three legs and you want to be able to retry each leg
> > if it fails
> > > and if it continues to fail you then want to roll back the entire
> > > transaction.
> > >
> > > How do you structure the methods and their transaction
> > attributes to support
> > > this?
> > >
> > > The key here is that just because you fail to plan a leg
> the first time
> > > doesn't mean that you will roll back everything. However, if
> > you continue to
> > > fail you will want to roll back everything that took place before.
> > >
> > > Can somebody describe the transaction attributes if you have
> > >
> > > planTrip()
> > > purchaseFirstLeg()
> > > purchaseSecondLeg()
> > > purchaseThirdLeg()
> > >
> > > What would the transaction attributes have to be for this to work?
> > >
> > > What I don't understand is if you need to be able to both
> > rollback just an
> > > individual leg and also have the flexibility to roll back the
> > planTrip all
> > > together. How can you do this when you use
> TX_REQUIRES_NEW for the inner
> > > legs and choose not to keep conversational state that indicates
> > failure with
> > > any one inner level?
> >
> > ==================================================================
> > =========
> > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > in the body
> > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
