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