On Fri, 5 Mar 1999, Nishi Nidamarty wrote:
> Nishi Nidamarty wrote:
>
> > Rickard �berg wrote:
> >
> > > Hi!
> > > However, this
> > > would require that the bean was stored (i.e. serialized) prior to the
> > > invocation. Is this the intent of the spec. (Vlada?), and are any
> > > vendors implementing it this way? Is the SessionSynchronization-interface
> > > supposed to cover this?
> > >
> >
> > Yes. the javax.ejb.SessionSynchronization has the notification mechanism to
> >
>
> > handle rollback/recovery in transactions that involve session beans.
>
> I felt my earlier message was kind of confusing :
> Here what I mean is that the SessionSynchronization interface provides the client
> using the session bean with some notification mechanism like the afterCompletion
> regarding the state of the transaction, it is up to the user how he maintains the
> state once he gets the notification. The SessionSynchronization does not provide a
> way to save the state.
> To my understanding the EJB vendor need to provide the actual implementation of
> this SessionSynchronization interface.
Nope. SessionSynchronization is implemented on the bean implementation
class, not on the client. (And it's only allowed for stateful session
beans). It's a callback interface, similar to the SessionBean interface
(that is, the container invokes methods on it to tell you that various
things have happened). The container invokes methods on the
SessionSynchronization interface to notify the bean of transaction
boundaries.
===========================================================================
Tom Valesky -- [EMAIL PROTECTED]
http://www.patriot.net/users/tvalesky
===========================================================================
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".
