I'm not sure exactly what you mean by Asynchronous Transaction, but
asynchronous makes me think of MDBs.  If you have a SFSB that invokes a MDB
via JMS, they will be two different transactions.  Transaction context does
not flow along with JMS messages.

The SessionSynchronization interface is used to synch the state of the SFSB
itself with the transaction (the container does not manage/rollback the
attributes of the SFSB itself).  These methods are called by the container,
not by the developer.

Ken


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

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

Reply via email to