Matthias David wrote:
>
> Hi,
>
> I have two questions on transactions.
>
> 1. Is it possible to remove Beans that are currently registered in a
> transaction? For example Bean A invokes Bean B, removes Bean B, invokes
> Bean C and finally commits the transaction. Is it an error to remove
> Bean B although the transaction has not yet been commited?
Yes, it is an error to remove bean B. The container should throw
an exception to the effect that bean is still associated with a
transaction.
>
> 2. The Spec says that nested transactions are not supported by now. But
> I think that nested transactions can be simulated:
> a) Client calls Bean A. Bean A (e.g. the container) creates new TX
> TX1.
> b) Bean A does something then calls Bean B which creates new TX TX2.
> c) Bean B does something in TX2, commits or rolls back and then
> returns to Bean A indicating whether TX2 was commited or rolled back.
> d) Bean A checks if the "nested" Transaction TX2 was succesful. If
> not it calls setRollBackOnly().
>
> So from my understanding this is a nested transaction. TX1 only
> commits if TX2 was commited. But I guess there must be a mistake. So
> what's wrong here?
For starters, let us assume that you invoked commit on TX1 but
for reasons beyond your control, TX1 was aborted. TX2 will remain
committed : something that would not happen in a Nested Transaction
model.
Cheers,
Sanjay
>
> Thanks,
> Matthias David, University of Karlsruhe, Germany.
>
> ===========================================================================
> 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".
