On Fri, 5 Mar 1999, Rickard [iso-8859-1] �berg wrote:
> Hi!
>
> Consider the following:
> If I have a stateful sessionbean which is marked with TX_REQUIRES_NEW,
> and a method is invoked which updates some variables in the bean, but
> before it can return the tx is for some reason rolled back. What will
> happen with the state of the bean?
According to my interpretation, nothing. The conversational state of a
session bean is not transactional.
> Since it is transactional one would imagine that the state would be
> restored to what it was before the method was invoked. 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, this is what SessionSynchronization is for; it allows you to make the
state of your beans (sort of) transactional (by hand). I say "sort of"
transactional because they're still just session beans, so they don't have
the Durability property of ACID transactions unless you put it in
yourself. Basically, if I wanted transactional conversational state
variables in a stateful session EJB, here's what I'd do:
1) In afterBegin(), stash your conversational state somewhere (in a
database, in a set of object variables, whatever).
2) Fiddle with your object state as necessary.
3) If you get afterCompletion(false), copy the initial state back from
wherever you stashed it into your object variables, so your state reverts
to what it was before you started performing work in the transaction.
4) If you get afterCompletion(true), do nothing -- the transaction
committed, so your state should be in sync with whatever else you did
during the transaction.
there were a TransactionalSessionBean (or maybe just a new flag,
TRANSACTIONAL_SESSION, in addition to STATEFUL_SESSION and
STATELESS_SESSION), but that's a spec issue. Also, I wonder what the
implementation would look like; for example, if you store the state at the
beginning of the transaction, store it again if the transaction succeeds,
and load it from the store if the transaction fails, haven't you just
created an entity bean under another name?
===========================================================================
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".
