• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Best - CMT or BMT?

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Thx
Raj
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can someone present a scenario where CMT does not work well and BMT becomes inevitable :roll:
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Paul
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Makes sense. Thanks for the answer Paul.
 
Ugly Redneck
Posts: 1006
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi..
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.
Regards
Sriraj
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic