Article:
  Bean-Managed Transaction Suspension in J2EE
Subject:   Point?
Date:   2005-07-22 09:44:39
From:   maximdim
Response to: Point?

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.

Main Topics Oldest First

Showing messages 1 through 1 of 1.

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