Transaction approach

Question

for transaction what is the recommended approach? Container-Managed or Bean-Managed? In my case I dont have any Entity beans. What about JTA?
Thanks

Answer 1

Thanks for your reply.
So the bean-managed transactions are not used
anymore. Regarding the container-managed transactions
I have some questions:I'll do my best here and admit from the start that I don't consider myself an expert.
* According to tutorial, the transaction starts
immediately before an EJB method and commits the
transaction just before the method exits.
Suppose I have 2 EJB methods: method1() which updates
Table A and method2() which updates Table B. Now in
my unit-of-work I have to call these 2 methods as
part of one transaction. I want to commit only when
both these methods pass else rollback both.
So I created another EJB method method3() which calls
method1() and if successfull calls method2(). Suppose
method 1() passes but method2() fails. In this case
how can I rollback the method1()? According to
tutorial its not possible.Then it's not possible.
Unless you can come up with something that says you CAN make method3 work I'd suggest that you refactor those methods so they can be in one EJB and execute a single unit of work.
I'd urge you to dig deeper into docs on this. It's perfectly reasonable to have CMPBeanA make to TableA and CMPBeanB map to TableB and want to have both participate in a single transaction. Perhaps the tutorial you're looking at isn't demonstrating the full power of the EJB container. Read ahead in the book and look at the XA declarations.
If that's not the case you have to refactor your EJBs a bit.
* According to tutorial, nested or multiple
transactions are not allowed within an EJB method.
What is the work-around to get this functionality? But you can persist CMPBeanA and CMPBeanB with NEW_TRANSACTION_REQUIRED. Your method3 would have the XA declaration, instantiate the beans, and have them as part of its unit of work. That's okay, I think.
* In some cases (when my unit-of-work needs to work
with only one database) I should use JDBC in other
cases (when unit-of-work needs to work with multiple
databases) I should use JTA. Is it right? You can use JDBC for transactions with only one database. JTA is required for one OR more than one database. That's my understanding.
But this is
mixing the 2 strategies. Should not I rely on one
strategy. If yes then JTA makes more sense. But what
will I loose when I go with JTA for a single database
environment as compared to JDBC?I don't think you lose anything. The one advantage to JDBC is that you can write the code yourself and have complete control. The bad news is that you have to write the code and you have complete responsibility.
* I am thinking about creating a seperate class for transaction management. It may have methods :
beginTransaction()
commitTransaction()
rollbackTransaction()
endTransaction()Why, when the developers of JTA have already done it (and better than you or I would be able to manage)?
These methods may manage a JDBC or a JTA transaction
depending upon the configuration (a properties file
may sepcify what to use: JDBC or JTA). My EJB methods
will call this class to manage transactions.
Is it a good idea? Or would it be too complicated a
route?Unless the JTA docs made it sound too hard to learn, I'd always rather use something that someone else wrote.
I'd recommend Spring. It has JDBC classes that will make writing DAOs MUCH easier than rolling your own. And you can take advantage of its declarative, AOP-based transaction support. Learn Spring. It's very capable and a great resume item. 8)
Don't roll your own until using JTA hits a brick wall.
%