Article:		Bean-Managed Transaction Suspension in J2EE
Subject:		Point?
Date:		2005-07-21 21:45:02
From:		hbarua
IMHO, the reason there was a UserTransaction interface was to clearly separate out the roles and responsibilities of BMTs and CMTs. Forcibly trying to extract the TM probably indicates that the app is not configured properly for transactions. If the J2EE spec does mandate exposing the TM in future versions of the spec that would of course be useful to frameworks like Spring (and also most of the OR mapping tools which use transactions). The tricks described here would just lead to non portable applications, apart from leading to possible inconsistencies.

Showing messages 1 through 8 of 8.

• Point?
  2005-07-22 06:34:10  maximdim [View]
  
  
  I'm not advocating for this approach to replace CMT, by all means if CMT is sufficient for particular task one absolutely should prefer to use it over BMT. But in real life there are some (albeit rare) situations when you have to have flexibility of BMT in your code and also may have a legitimate reason to suspend/resume transactions. This article explains exactly that - how to do it when you need it.
  Moreover I hoped to bring a little bit more light how Spring makes 'transactional proxies' functionality work, because I think it's important for developers to understand internal 'kitchen' of framework they're using and possible problems/limitations it imposes.
  J2EE spec is not a dogma, and looking up TM doesn't make your code less portable than say using container-specific deployment descriptors. Even so in this article sample code to lookup TM intentionally simplified, there is a perfectly legal way to do it without introducing dependencies on any container-specific classes so your code would work in any container (see Spring sources for details if interested).
• Point?
  2005-07-22 09:13:56  hbarua [View]
  
  
  >> This article explains exactly that - how to do >>it when you need it.
  Yes it makes sense from that perspective. Thanks for pointing it out.
  
  >>I think it's important for developers to >>understand internal 'kitchen' of framework >>they're using and possible problems/limitations >>it imposes.
  Absolutely agree with this.
  
  
  >>J2EE spec is not a dogma, and looking up TM >>doesn't make your code less portable than say >>using container-specific deployment descriptors.
  
  
  I didn't say it's a dogma - the nonportability can come about because certain appservers might have restrictions on the methods you can use on the exposed Transaction Manager. As long as it's not a standard one can never be safe in assuming it.
• Point?
  2005-07-22 09:44:39  maximdim [View]
  
  
  the nonportability can come about because certain appservers might have restrictions on the methods you can use on the exposed Transaction Manager. As long as it's not a standard one can never be safe in assuming it.
  
  True. You cannot be sure 100% that TM is available and/or behave properly in any possible container (as shown in article for example there is at least one known problem with TM in WLS). But in the majority of cases it's there and works as expected.
• Point?
  2006-06-05 13:55:47  ejbRules [View]
  
  
  No, it does not work as expected. Spring was broken 3 different times because the TM was changed in 3 different versions of WebSphere. Anyone that writes code that plays with the native TM is playing with fire.
  
  Instead of going through all this stupid trouble to write non-standard code and to use hidden APIs one ought to just follow the EJB spec and use the transaction setting of "NotSupported" or "Never" then the developer will have portable code that works on any J2EE app server. Advocating to write directly to the TM is foolish and shows lack of experience. We lived through the days when people used hidden DOS 21h functions and seeing code break with new versions of DOS. This article does nothing more than advocate the same mistakes people made 20 years ago.
  
  Stick to using EJBs they way they are meant to be used and you can have portable, transactional code just like is needed by the use cases stated and one does not have to take unnecessary risks to write code that will break one day (probably when a fix or new version is applied).
  
  
• Point?
  2006-10-12 01:59:06  toddiuszho [View]
  
  

  I am using POJO Entities that coordinate with JPA and UserTransaction for ORM. On top of that, I want POJO DAOs that emulate CMT.

  
  
  

  I do not want EJBs. I do not need to remote my objects. I do not want to write tons of interfaces and classes for every DAO. No thanks.

  
  
  

  My POJO DAOs will use my own custom Annotations that emulate javax.ejb.TransactionAttribute. Using Spring and AspectJ and advice in this article, I now have an idea of how to write my advice blocks.

  
  
  

  And THAT is the point. I don't want to sacrifice the ease of declarative transaction demarcation just because my software needs do not justify the heavyness of the rest of EJBs.

• I think you're missed the point...
  2006-06-06 12:47:00  MaximDim [View]
  
  
  The main point of this article was not to convince anybody prefer BMT over CMT or other way around or to mess with TransactionManager, but to demonstrate how Spring (and other frameworks) are collaborating with J2EE container in terms of transaction management. The API they're using is not 'hidden' by any means, it's part of Java JTA API, moreover EJB container is using pretty much identical code internally to manage transactions.
  
  No matter how you feel about it, Spring is used more and more inside J2EE containers and I think it's beneficial for developers to have at least basic understanding of how it communicates with transactions.
  
• Re: Point?
  2005-07-22 09:12:51  hbarua [View]
  
  
  >> This article explains exactly that - how to do
  >>it when you need it.
  Yes it makes sense from that perspective. Thanks for pointing it out.
  
  >>I think it's important for developers to
  >>understand internal 'kitchen' of framework
  >>they're using and possible problems/limitations
  >>it imposes.
  
  Absolutely agree with this.
  
  
  >>J2EE spec is not a dogma, and looking up TM
  >>doesn't make your code less portable than say
  >>using container-specific deployment descriptors.
  
  I didn't say it's a dogma - the nonportability can
  come about because certain appservers might have
  restrictions on the methods you can use on the
  exposed Transaction Manager. As long as it's not a
  standard one can never be safe in assuming it.
• Point?
  2005-07-22 09:10:01  hbarua [View]
  
  
  >> This article explains exactly that - how to do >>it when you need it.
  Yes it makes sense from that perspective. Thanks for pointing it out.
  >>I think it's important for developers to >>understand internal 'kitchen' of framework >>they're using and possible problems/limitations >>it imposes.
  Absolutely agree with this.
  
  >>J2EE spec is not a dogma, and looking up TM >>doesn't make your code less portable than say >>using container-specific deployment descriptors.
  I didn't say it's a dogma - the nonportability can come about because certain appservers might have restrictions on the methods you can use on the exposed Transaction Manager. As long as it's not a standard one can never be safe in assuming it.