Re: Rolling back Asynchronous TXN

[Deyan D. Bektchiev]

Joe,

You should explain what is your definition of "asynchronous transaction"
before anyone will be able to fully understand your issue.
You are not restricted to registering only SessionSynchronization to get
the callbacks for a transaction (before/afterCompletion(), and there is
no afterBegin() anywhere in JTA/JTS).
You can have a simple standalone class that implements
javax.transaction.Synchronization interface that will get all of the
callbacks no matter what the outcome is (I doubt that the
SessionSynchronization is not called if the transaction is rolled back
since the container can remove the instance from it's pool but cannot
just destroy it...I haven't tried this so I might be wrong).
You can register that synchronization at anytime after the start of the
transaction provided you can get a reference on the transaction itself
(the EJB spec mandates that an EJB container makes the
TransactionManager available via JNDI so you can look it up and then get
the transaction).
HTH,
Dejan
[EMAIL PROTECTED] wrote:

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".




--
Deyan D. Bektchiev
Application Networks
444 Ramona St
Palo Alto, CA94301, USA
email:  [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Tel: +1 650 289 1046
Fax: +1 650 462 7221
www.application-networks.com <http://www.application-networks.com/>