File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Best - CMT or BMT? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Best - CMT or BMT?" Watch "Best - CMT or BMT?" New topic

Best - CMT or BMT?

Raj Rad

Joined: May 20, 2002
Posts: 10
As per the J2EE Blueprints,
1)The recommended way to manage transactions is through container-managed demarcation.
2)Transaction demarcation should be selected with great care by someone who understands the application well. Bean-managed transaction demarcation is only for advanced users who want fine-grain control over the transactional behavior of the application.
So which is the better way? EJB spec doesn't say the applicability clearly. J2EE tutorial also repeats the term 'fine-grain' control for the applicability of BMT.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
The J2EE Blueprints clearly state that CMT is preferred and to use BMT only when CMT will not meet the requirements. I think nearly everyone will agree that CMT is the most maintainable solution.
Ajith Kallambella

Joined: Mar 17, 2000
Posts: 5782
Can someone present a scenario where CMT does not work well and BMT becomes inevitable :roll:

Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Paul Lester
Ranch Hand

Joined: Dec 27, 2002
Posts: 40
I can think of one instance when I considered BMT, but decided against it because I figured out a way to do it using CMT.
The only time that I considered it was in having to access 2 different databases inside of one transaction. I didn't have/or need 2 phase commit protocol because DB-1 was read only and DB 2 was to be updated. If you are inside of a transaction scope the container will not let you start another transaction with a different database. In this case it would have been good if I could have suspended one transaction and done a non-transactional call, etc.
I was able to accomplish what I wanted by calling the lookup on the other database through a session bean that didn't participate in transactions ... so, the container handled it for me.
BMT is potentially error prone because you can throw exceptions and go around your commit or rollback statements, etc. I've been using EJB for about 2 1/2 years and have never had the need for BMT.

Where Photography meets vision.<br /><a href="" target="_blank" rel="nofollow"></a><br />Please stop by!<br /> <br />SCJP,SCWCD,SCJD,SCEA
Ajith Kallambella

Joined: Mar 17, 2000
Posts: 5782
Makes sense. Thanks for the answer Paul.
Paul McKenna
Ugly Redneck
Ranch Hand

Joined: Jul 08, 2000
Posts: 1006
Here is an example of when you might want to consider BMT.
We had an application that invoked a transaction on an Oracle database. The transaction was huge.. it involved cloning of 100s of 1000s of records and spanned multiple tables. We were using IBM Websphere to manage these transactions. The CMT scenario always failed(time out) or had some dang problem. So we had to recode the transaction using BMT. While I definetly do not recommend BMT in any other case.. it had to be used because of container limitations.
Hope that helps.

Commentary From the Sidelines of history
I agree. Here's the link:
subject: Best - CMT or BMT?
It's not a secret anymore!