How to synch data in Ldap and Oracle in a single transaction?

[cindy wang]

This is a typical 3-tier J2EE application with Jsp, Servlet and EJB. I had some data stored in Ldap and some in Oracle. To update data and keep integrity, I must keep update to Ldap and to Oracle in a single transaction ( update to ldap and Oracle are done in a method of EJB, and EJB's transaction attribute is set "required"). But Ldap seems not support transaction and rollback. How should I do? Thanks in advance.
--------------------------------------------------------------------------------

[Dave Landers]

One solution is to do your LDAP work in a Stateful Session that implements the SessionSynchronization interface.
You would cache all the changes in the session's state, and only write to LDAP when you get a transaction completion callback from the container.

[cindy wang]

Hi Dave,
Thanks for your reply. But for the sake of performance and cluster, I'd like to use stateless session bean. Can I still use SesionSynchronization interface for statelss bean? Since I never use it before, can you show me some snippet( or pseudo code)?
Thanks

[Chris Mathews]

SessionSynchronization can only be used with a Stateful Session Bean. The interface involves additional lifecycle methods that do not make sense in the context of a stateless operation. There is nothing to say that your Stateful Session Bean can't have just one operation though.

[cindy wang]

Now I know that only stateful session bean using container-managed transaction may optionally implement SessionSynchronization. But is there any workaround if I insist using stateless session bean in consideration of performance and clustering?
Thanks.

[Dave Landers]

You could write something like a JDBC Driver/Connection, and support all the transactional behavior of JDBC. Then you could connect to it via a datasource and the container would know how to talk to it. You'd need to do some sort of translation between LDAP and JDBC, including support of an sql-like language. Qutie a lot of work.
I am not too familiar with JCA, but you might also be able to make your LDAP thingy a JCA adapter. Not sure about this.
The problem is that you need some way to interact with the transaction via the container. That means you have to get some kind of callbacks from the transaction manager.
No matter how you implement things, in order to support the transactional behavior you will have to maintain some state somewhere to remember the things that happened during the transaction. Why not let the container manage this for you with a Stateful Bean. As for clustering, the container is supposed to support that for you if you stick with supported APIs.
Without container support (like a stateful bean), you will need to write a lot of transaction code plus the state management code plus whatever you might need to support clustering (possibly appserver specific). There's probably more to it than that. Why not let the container help you with the supported SessionSynchronization API?

[cindy wang]

Let me say in detail what I'd like to do:
Method A
{
update to LDAP
}
Method B
{
update to Oracle
}
Method C
{
call method A;
}
So if I define both update to LDAP and update to Oracle in a

[cindy wang]

Sorry , last message is a typo. From my understanding, it seemed that Dave think I will use bean-managed transaction. What I really mean:
Method A
{
update to LDAP
}
Method B
{
update to Oracle
}
Method C
{
call method A;
call method B;
}
A, B and C are methods of session bean.
Case 1: If I use stateless bean with container-managed transaction, what tran attribute shall i set for A, B and C? Should I use "RequiresNew" for C, "Required" for A and B? How to keep integrity between LDAP and Oracle? Or I have no way to do this because LDAP doesn't support tran and rollback except bean-managed tran?
Case 2: If I use stateful bean with container-managed transaction implementing SessionSynchronization, what tran attribute shall i set for A, B and C?
Thanks for your kind help and I am frustrated with this for a long time.

[Dave Landers]

If you use the SessionSynchronization technique, you will have to use CMT.
For some reason, the stateful requirement put you off, so you asked what else you could do. Well, the only other things you can do are to actually interact with the transaction manager directly. Actually, I don't think you can do what you want with stateless bean and BMT - maybe not even stateful bean with BMT. I think you must go deeper (or use SessionSynchronization).

I think Case 1 will not work. No matter what transaction attributes you set for CMT, it will not let you rollback the LDAP update in Method A.
Using BMT will not help either because BMT only lets you start/stop/manage transactions, but does not add any features to give you commit or rollback callbacks.
Case 2 will work (SessionSynchronization). I would probably put the "update to LDAP" in its own stateful session bean that does nothing but LDAP. Call that bean from Method A of a stateless session bean.
This UpdateLdapBean will have methods to update the data - but these will not actually talk to ldap, they will only cache the information in the bean's state. You only make ldap changes if the transaction commits and does not rollback.

Once you have that in place, you can choose the Transaction Attributes based on how the EJB needs to interoperate with other things. That is - what are the use cases?
When in doubt, Required is a good choice. I expect that you will want Required for A and B, and probably also for C.
But since you always want A and B to be called together in the same transaction, you might consider using Manditory for these.
The only reason you would want RequiresNew on C is if it is not allowed to participate in another transaction - this is usually not the case.
[ September 30, 2002: Message edited by: Dave Landers ]