Since you want to be able to retry without dooming the entire tx, this might
indeed be easier if done via a bean managed tx. My personal belief is that
you should avoid bean managed tx's unless you have a business rule which
truly requires it, and you may have such here. If you did not need the
retry, and were willing to doom the whole or part of the tx if it failed
without a retry this would be quite easy with container managed
transactions. But with the needed logic to retry N times before dooming,
this might be best handled with a bean managed tx, coodinated by a a session
bean which handled the enitre booking and retry.
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "Robert Nicholson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 07, 2001 1:55 AM
Subject: Trip planning problem... transactoin attributes?
> 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".
