Stateless session bean transactions

Question

I am working on a JSF web application. The service layer is developed using stateless session beans. These stateless beans are injected to managed beans using CDI.

I know that to manage transactions in stateless beans, I can use either container managed transactions or bean managed transactions. Also all the public methods in a stateless bean are by default in container managed transactions.

So my questions are:

Which is the preferred approach for transaction management in stateless bean - container managed or bean managed?

Is it advisable to have both bean managed and container managed transaction beans in service layer?

Is it possible to use both container managed and bean managed transactions in a single bean? If possible is it advisable?

Please let me know your suggestions...

Answer 1

Which is the preferred approach for transaction management in stateless bean - container >managed or bean managed?

The typical and preferred approach is to use CMT. Transaction management is one of the useful services that a app server offers, it simplifies your development, therefore, you should use this approach (that also is the default one) the vast majority of the time.

However, BMT is still necessary in some special cases:

a) when you need reduce the transaction boundaries for improving performance.

b) when you have a statefull session bean and you need retain a transaction across several client calls. (it's hard to see when this can be useful).

Is it advisable to have both bean managed and container managed transaction beans in service layer?

Yes, If some services need the special requirement described above, you can use both bean transaction types as part of the service layer.

Is it possible to use both container managed and bean managed transactions in a single bean? If possible is it advisable?

No, it is not possible.

Answer 2

Use container managed transaction if your transaction scope does not span across more service layer methods: ideally you should have one transaction (container-triggered commit) for one method. If this is not the case, a bean managed transaction should be more practical, letting the caller decide when commit or rollback.