Container handles transaction commits when using container managed
demarcation. For rollbacks you have two options:
1. Any bean in current transaction context (chain of beans which belongs to
the same transaction) can "vote" for a rollback using
EJBContext.setRollbackOnly().
2. Exceptions: Basically all unchecked execptions causes current transaction
rolled back. With application level execptions you have a chance to recover.
With bean managed demarcation you handle commits and rollbacks yourself
using UserTransaction. This is no-no for entity beans in 1.1 spec.
Also transactional attributes effects on these conditions (e.g.
TX_NOT_SUPPORTED is a different case)
Maybe you want to take a look at Richard Monson-Haefel's book (Chapter
Transactions). Also EJB spec 1.1 Chapters 11 and 12 cover these issues.
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Eyal Hirsch
> Sent: Tuesday, February 23, 1999 2:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: BMP and Transactions
>
>
> > You don't need to suspend a transaction in your Bean code. The container
> does it for you. When writting >EntityBeans (no matter BMP or CMP), you
> don't need to care about transactions, since they are always
> >managed by the
> container.
>
> I stand corrected, forgot about it. how about stateless session
> beans for example with client demarcation transactions ?
>
> eyal.
>
> ==================================================================
> =========
> 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".
