You can get informed of transaction boundaries when you implement the
SessionSynchronization interface. But this is only the
half way: You have to implement code to react in a correct way to this information, i.
e., if you get a rollback, you have
to do this rollback on your own. On the other side, you can specify from inside you
bean that a situation occured that makes
impossible to do a commit, and so you can please the container to end the transaction
by Rollback instead of Commit. I think
this two things (reacting corresponding to SessionSynchronization, setting "End with
Rollback" from inside you bean) is all
you need to write a save bean.
> Philippe and all,
> I am investigating into a problem that involves
> transactions. I am a newbie to EJB and transactions.
> So I request a little help.
>
> From what I read about "Flat Transactions", for
> persistent data stored in a DB, EJB commit/rollback
> involves calling commit on the underlying DB or
> lack of it.
>
> What if the underlying data store is say a LDAP Directory
> Server? In our project, we are storing some essential
> data in a LDAP directory server and perform all possible
> operations on this data such as insertion/modification/
> retrieval/deletion etc.
>
> The problems here are mainly of Atomicity and
> Machine/Network failure and not so much of concurrent
> updates, due to the nature of operations involved. Let me
> give an example. Ours is a Java application that accesses
> LDAP directory server through JNDI. Suppose the user
> has requested a certain operation. This might in turn
> involve invoking a series of operations on LDAP through
> JNDI. What if the host/network fails after a few of these
> operations are completed? We have identified situations
> where the results could be disastrous.
>
> Suppose we decide to provide these operations through
> a Session (possibly stateless) Bean, does EJB provide
> any help in implementing transactions? Or do we have to
> provide our own solution. In the latter case, it might
> even be better for us not to make use of beans due to
> the threading issues involved. Please advise.
> sincerely,
> Ramesh Mantri
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-users".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
