Article:		Bean-Managed Transaction Suspension in J2EE
Subject:		Point?
Date:		2005-07-22 09:13:56
From:		hbarua
Response to: Point?
>> 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.

Showing messages 1 through 4 of 4.

• 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.