I realize that the container will discard the instance. That is not the
issue. The issue is that an asynchronous activity has already occurred.
That activity, in my case, has updated data in a relational database. Now,
those updates will be out of synch with tables updated through more
"traditional" EJB activity, such as:
- CMP/BMP beans called before or after the asynchronous call,
session bean updates of tables,
DAO updates of tables
In short, whatever "traditional" updates have occurred which are within the
transaction boundaries described by "this" Stateful Session Bean.
Since this bean is being discarded due to a Runtime Exception being thrown,
it is my understanding that not only is the bean instance discarded, but
that the transaction is also rolled back. Because of this rollback, all the
"traditional" updates are rolled back.
However, the "asynchronous" transactions, I believe, are NOT rolled back
"automatically".
THAT is why a person uses the SessionSynchronization interface. It is
PRECISELY to handle these types of errors. It is my understanding that you
use the methods defined by this interface to capture start of transaction
boundary, "near completion" of the transaction boundary, and completion of
the transaction boundary.
However, since a runtime Exception will cause the instance to be discarded,
and the transaction to be rolled back (without calling the "near
completion" OR "completion" methods...), one needs to guard against such
failures in a way which will guarantee that the asynchonous activity is
"restored" to its pre-transaction state.
That is the crux of what I am asking.
Joe
Johan Eltes
<[EMAIL PROTECTED] To: <[EMAIL PROTECTED]>,
llista.se> <[EMAIL PROTECTED]>
cc:
02/24/2003 Subject: Re: Rolling back Asynchronous
TXN
09:49 PM
Hi!
When a runtime exception hits the container, it is required to discard the
bean instance. So there is no bean that could be the target of a container
callback :-)
/Johan
Den 2003-02-20 17.56, skrev "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>:
> It is my understanding that rolling back Asynchronous transaction is best
> accomplished by using a Stateful Session Bean implementing the Session
> Synchronization interface.
>
> If I understand this correctly, one should:
>
> 1. capture "recovery state" info, perhaps in method afterBegin()
>
> 2. review the status of "transaction committed" state in method
> afterCompletion( boolean committed )
>
> 3. If (! committed ) { recoverAsynchronousState(); }
>
> My question:
> When a runtime exception occurs, ongoing transactions are rolled back,
but
> afterCompletion( boolean committed ) will NOT be called.
>
> Does anyone have an elegant solution for handling such errors? I have
been
> using a crude framework:
>
> private boolean txnInprogress = false;
>
> public void afterBegin() { txnInProgress = true; }
>
> public Whatever remoteMethod() throws Exception {
> try {
> // do some work
> } catch Exception ex ) {
> if ( txnInProgress ) {
> afterCompletion( false );
> }
> throw ex;
> }
>
> public void afterCompletion( boolean committed ) {
> if (! committed) {
> // roll back asynchronous txn
> }
> // other work
> }
>
>
===========================================================================
> 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".
