I hate when someone nitpicks a simple example that I post. I hope this isn't
considered nitpicking.
Because memento and state are object references, setting memento = state,
and state = memento for a rollback, won't accomplish what you intend.
Instead, StateHolder could implement cloneable, and you could call the clone
method to save and restore the object's member variables.
Also, memento can be declared transient, and you wouldn't have to worry
about *any* passivation of this variable.
jim
----- Original Message -----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 09, 1999 8:15 AM
Subject: Re: Stateful session bean state
> No. This would be the case with an entity bean but not a stateful session
> bean. You can, however, have the bean implement the
SessionSynchronization
> interface so that you are aware of the outcome of a transaction can use
the
> memento pattern to roll the bean's state back the way it was before the
> transaction started.
>
> public class MySession implements javax.ejb.SessionBean,
> javax.ejb.SessionSynchronization{
> public StateHolder state;
> public StateHolder memento;
>
> public void afterBegin( ) {
> memento = state;
> }
> public void afterCompletion( boolean committed){
> if( ! committed){
> state = memento; // roll back state
> }
> memento = null; // less to passivate outside of a
transaction
> }
> }
>
> public class StateHolder implements java.io.Serializable{
> public int id;
> public String name;
> public Employee empBean;
> }
>
> Note: The assumption here is that server is smart enough to preserving
things
> like a bean reference within the StateHolder.
>
> Richard
>
> --
> Richard Monson-Haefel
> EJB Expert for jGuru.com
> ( http://www.jguru.com )
>
> Author of Enterprise JavaBeans
> Published by O'Reilly & Associates
> ( http://www.ejbnow.com )
>
>
> "Kiely, Conor" wrote:
>
> > Question: Does the container have any responsibilities for managing the
> > state
> > of attributes in a stateful session bean where a transaction might roll
> > back ?
> >
> > I'm not talking about serializing the state on passivation.
> > I'm talking about attributes modified within (say) a TX_REQUIRED
> > method, which rolls back after the attribute state has been updated.
> >
> > Can/should the container restore the pre-transaction attribute state ?
> > I can't see mention of this (or maybe I'm not 'getting' it), but it
> > would be 'nice'.
> >
> > Conor.
> >
> >
===========================================================================
> > 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".
>
===========================================================================
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".
