Peter Holditch

This month I was again inspired by the weblogic.developer.interest.transaction newsgroup on newsgroups.bea.com - if you weren't listening last time I plugged this newsgroup, listen now; one day, it might save your life!

Be Paranoid, Be Very Afraid
A quick guess at what "NotSupported" does might lead you to wonder if it's just a repeat of Never and worry about the redundancy, whilst musing on "Supported" might make you paranoid about what is really going to happen at runtime. Well, be very afraid of these two innocent- sounding attributes!

As you know if you've used EJB container-managed transactions, you have several options available in declaring your methods' transactional behavior, namely NotSupported, Required, Supports, RequiresNew, Mandatory, or Never. I guess the one with the clearest intent is "RequiresNew" - the method requires a new transaction context, so the container will create one before running the code. Next, "Required" - a transaction is required to run this method, so if the caller didn't supply one, the container will create a new transaction context for the method to run in. In "Mandatory" - the method requires a transaction context and it's an error by the caller to not supply a transaction context prior to the call. Then "Never" - a transaction context must never exist when this method is called, and if one does it's an error. There are still two more options, Supports and NotSupported; these are much less imperative sounding than the other choices and, as always in software design, precision is everything!

"The Supports transaction attribute must be used with caution. This is because of the different transactional semantics provided by the two possible modes of execution. Only the enterprise beans that will execute correctly in both modes should use the Supports transaction attribute." (Section 16.7.2.3)

This is clearly bad news, and anyone with any sense will take this as a cue to give Supports a wide berth unless there is a very good justification for not doing so.

However, the spec gives no such warning about the NotSupported behavior, which I think is rather odd since it is even more dangerous.

The spec argues that the danger with Supports is that it makes your methods behave in different ways, depending on the calling context. This obviously is a bad thing, encouraging close (and hard to spot) coupling between the caller and callee and generally breaking the laws of good practice. At least Supports always behaves in the same way. What's not so clear from this section of the spec is in what consistent way this will behave. It simply makes the innocent-sounding statement that "The Container invokes an enterprise bean method whose transaction attribute is set to NotSupported with an unspecified transaction context." (16.7.2.1)

We Need Scooby Doo!
To get to the bottom of this mystery, we need a detective. After staking out the spec for a while from behind a bush we notice a light on after hours in section 16.7.5. In fact, this whole section is a horror story about the kind of things containers get up to in "unspecified transaction contexts" - I'll not quote it verbatim here, my fingers daren't type that kind of horror, but suffice it to say, containers can do whatever they like - start a new transaction per call, start a new transaction and lump multiple calls together in it, run with no transaction context at all. This all adds up to bad news. Your bean's behavior will change from application server to application server (and could even legitimately change between releases of application server) all this adds up to... zoinks! Portability problems. Which was one of the things you set out to mitigate by using J2EE in the first place. As a footnote, WebLogic's behavior in this situation (in the current release!) is to execute methods on Entity beans in their own fresh transaction context (equivalent to the RequiresNew behavior) and to execute methods on session beans with no active transaction (equivalent to a bean managed bean that hasn't started a transaction).

So, we have unmasked the felon - the innocent-looking unspecified transaction context! Remember kids, the moral of the story is: Don't use NotSupported, Never, or Supports for your container managed transactions, or you'll store up a whole load of grief for yourself (or for whoever inherits your code to maintain!).