Dejan,
"the EJB spec mandates that an EJB container makes the TransactionManager"
- A pointer to the spec would be much appreciated.
/Johan
Den 2003-02-27 00.16, skrev "Deyan D. Bektchiev" <[EMAIL PROTECTED]>:
> 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/>
>
>
>
===========================================================================
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".
