I would set up planTrip() as RequiresNew, and each of the purchase methods with
Required or Supports. I don't understand your exact criterion for rolling back, but if
you need to have more than one leg fail then
don't throw an EJBException from the purchase methods. Instead, have them return a
value or throw an application exception to planTrip and give it the smarts to
determine whether the whole thing needs to roll
back and have it throw EJBException at that point.
3/6/2001 2:55:39 PM, Robert Nicholson <[EMAIL PROTECTED]> 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?
>
Jeff Sahol
[EMAIL PROTECTED]
===========================================================================
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".
