[snip -- is SessionSynchronization a client-side 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.
>
> Yep that makes sense.
> What about client demarcated transactions which make use of stateless
session beans
>?
Only stateful session beans can implement the SessionSynchronization
interface. (Its
purpose is to keep the bean's state in sync; if there's no state, there's no
need for it).
> How does the client get notification of the transaction boundaries in
such a case ?
> Are there any interfaces that support such notification in client
demarcated
>transactions ?
In such a case, the client is in charge of the transaction boundaries. :-)
Also, they can use
the javax.transaction.UserTransaction.getStatus() method at any time to find
out the state
of the transaction. (A bean participating in such a transaction can use it's
EJBContext.getRollbackOnly()
method to see if the transaction in which it is executing has been marked
for rollback).
===========================================================================
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".
