Win a copy of High Performance Python for Data Analytics this week in the Python forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
  • salvin francis
  • Frits Walraven
  • Piet Souris

Bean provider's responsibilities with exceptions and...transactions

Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, on HF, page 542, I'm reading the Bean provider's responsibilities for application exceptions. The pages says:

'If you catch an application exception, and find that you can't continue the transaction, call setRollbackOnly() before throwing the exception to the Container.'

At this point I have got a doubt. In the chapter about transaction, I remember that it was clearly stated that only CMT beans with a transaction attribute set to 'Required', 'RequiresNew' and 'Mandatory' should invoke the setRollbackOnly() method, otherwise an exception (it seems to me IllegalStateException but I'm not sure) is thrown. But if the CMT transaction attributes are *NOT* responsibility of the Bean provider, how could the bean provider start from the perspective that the method will have only one of the three required attributes? Doesn't this limit bean's portability (one of the reason why CMT beans will be used most of the time)?

Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My opinion is that this is fundamental problem of the declarative txn management.

The txn attribute's value definitely affects the program's logic, and the txn attribute may be changed by someone (appli. assembler and deployer) not writing the code (bean provider). That means the program that can be compiled, deployed and running apparently normally will explode occasionally when, say, it needs to rollback something.

Although the spec does allow the Bean provider to supply the recommended value of txn attribute, there is no way to force AA and deployer to follow it!
If you want to look young and thin, hang around old, fat people. Or this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic