DAO transactions

[raj joe]

I have the following design

Jsp- ControllerServlet - BusinessDelegate (uses service loactor)- Sesssion Facade - DAO (using conection pool of App server)- DB


In this desing can u pls let me know i would i handle transactions.
Should i do it in DAO with autocommit (false) etc

OR

Can the session facade help me.

[Valentin Tanase]

Hi Raj,

In this desing can u pls let me know i would i handle transactions.
Should i do it in DAO with autocommit (false) etc

OR

Can the session facade help me.

My first advice would be to use CMT and set the appropriate transaction attributes in the deployment descriptors. If you believe that BMT only can achieve your project requirements, then you�d probably like to handle the transactions in your session fa�ade layer. The reason I�m saying that is mostly because it can help you to demarcate your transaction boundaries (specially when working with global transactions) better. As an example think about a method that gets some data from database and sends it to a jms destination. If you have your transaction boundaries defined in DAO then you won�t be able to include the jms work-unit. On the other hand if you�ll start the transaction within your SLSB you can include both calls like this:

UserTransaction txManager = context.getUserTransaction();
txManager.begin();
List someData = getDataFromDB();
sendDataToJmsDestination(someData);
txManager.commit();

And by the way, if you decide to go with BMT then better chose JTS/JTA over JDBC transactions and you don�t need to care about setting the autocommit.
Regards.

[Filip Pas]

I think it would be best to use transactions everywhere it's needed.
In general your dao's should have transaction required.
That way a transaction started in a stateless sessionbean is a whole unit encompassing the different calls to daos and or jms.
The only requirement for this to work is that you'll need two-phase commit
for all transactional resources taking part in the transaction.
All you have to do is define the transaction in the deployment descriptor.
(Or spring context if u're using spring).
Whatever you do don't code your transactions. It's not recommended. Sometimes just adding another method (with a different transaction propagation setting) to your sessionbean and calling it will end up the same as coding it. I sure hope you have the option of doing that else you'll be in for some pain...

[raj joe]

Originally posted by Valentin Tanase:
Hi Raj,

UserTransaction txManager = context.getUserTransaction();
txManager.begin();
List someData = getDataFromDB();
sendDataToJmsDestination(someData);
txManager.commit();

And by the way, if you decide to go with BMT then better chose JTS/JTA over JDBC transactions and you don’t need to care about setting the autocommit.
Regards.

I noticed in my previous project that all transcations where handled in the Stored procedures.We just call SP from the DAO and get the registered output paramaters.What are advantages and disadvantages of managing transcation in the SP aganist Java.

[raj joe]

Originally posted by Filip Pas:
I think it would be best to use transactions everywhere it's needed.
In general your dao's should have transaction required.
That way a transaction started in a stateless sessionbean is a whole unit encompassing the different calls to daos and or jms.
The only requirement for this to work is that you'll need two-phase commit
for all transactional resources taking part in the transaction.
All you have to do is define the transaction in the deployment descriptor.
(Or spring context if u're using spring).
Whatever you do don't code your transactions. It's not recommended. Sometimes just adding another method (with a different transaction propagation setting) to your sessionbean and calling it will end up the same as coding it. I sure hope you have the option of doing that else you'll be in for some pain...

In my session bean deployment discriptor,i can make transcations required at method level.How can i say at my DAO method level transcation "Mandatory" (Like in entity beans) so that it should always be part of the transcation.

I can pls expand on requiremnt for two phase commit in the above scenario.
I do I define that transcation required two phase commit.

[Valentin Tanase]

Hi Raj,

I noticed in my previous project that all transcations where handled in the Stored procedures.We just call SP from the DAO and get the registered output paramaters.What are advantages and disadvantages of managing transcation in the SP aganist Java.

The big disadvantage is that you tide your app to only one transactional system: the database. Hence you cannot implement global transactions, which might be ok if your app doesn�t require them. You might encounter portability issues if you�ll move to another database because your SPs must be rewritten. You might also notice that you have to write some code in order to implement your transaction management, while CMT would provide that for free. Hence maintaining CMT app might be easier though: if you need to change the transaction demarcation for example, you have to change your SPs as well. CMT enterprise beans don�t need any code changes.
However there are some advantages too. One big advantage is that you could provide a much more flexible transaction model this way. As you know, j2ee doesn�t support nested transaction. Having your transaction completely handled by your database you might achieve this goal (if your db supports nested transactions of course). Another advantage might be the direct consequences of using SPs: they are reliable and fast.
Regards.

[Filip Pas]

You can use spring to define transactions on your daos if they're regular pojos.