Peter Holditch

Picnicking during my summer holidays with my family, I was a little peeved to find that we had set up camp near an ant hill and some of them had decided to help themselves to elements of our lunch. Just as well, really, that I prefer sausage rolls and pork pies to chocolate buns, I guess. Every time I see an ant, I'm reminded of countless documentaries from my youth, waxing lyrical about how an ant can carry many times its own body weight.

Right now, the evidence is being played out in front of me, so at least you can believe some of what you see on TV. Isn't nature a miraculous thing! So what does this have to do with transactions? Well, very little actually.

Bear with My Ramblings, Won't You? I'm on Holiday!
I thought this month I would come up for air with a review of a piece of obsure knowledge about the WebLogic Server transaction manager implementation. As you probably realize by now, if you want to demarcate a transaction from a piece of Java code, you simply need to obtain a reference to the User Transaction object and start invoking its begin, commit, etc., methods at will. What could be simpler?

What may have escaped your notice (since the specs don't make a very big deal about it) is that you can do this wherever you want - in EJBs configured to use bean-managed transactions, in RMI objects, in startup classes, you name it. These are all server-side places; however, the list goes on.... You can also demarcate transactions from Swing clients or even Java applets. In fact, in an alarming throwback to flower power and Woodstock, you can do it wherever you please, on the server or off it. Think about that for a minute...coordinating a transaction (as you may remember from previous columns) requires transaction logs, which are the linchpin of your business data's integrity. You need to be very paranoid about these - put them on RAID disks, make them available to multiple machines for failover, prevent the intern system administrator from deleting them to save disk space, and so on. Now let's think about clients - potentially applets - not exactly where you'd keep your proverbial family silver, or your actual transaction log. So how can transactions be demarcated there? Visions of MS Internet Explorer (with the Java plug-in) powering over a picnic rug carrying a RAID disk array are spinning through my mind... I need to lie down, I'm overcome. Let's face it, this is technology, not the miracle of nature. There is no clever evolutionary mechanism to fall back on here.

What's Going on Behind This Choking Smoke and These Dizzying Mirrors?
As you may have guessed, the BEA engineers who wrote the transaction manager in WebLogic Server were well aware of the asymmetry between the client and server, and they engineered the infrastructure (they'd get cross if I carried the smoke and mirrors reference forward) to take care of it. If you get a reference to the User Transaction object on a client, the implementation is well aware of the lowly status of the container it's running in. It does all the usual stuff with respect to associating a transaction object to the relevant threads on the client, and propagates the transaction context across the wire when the client makes RMI calls to remote objects in the scope of a transaction. However, at commit time it knows its place. It packages all the information about the transaction and sends it to a server, where the commit processing can proceed in an environment more conducive to reliability and where the RAID disks and suchlike are kept. The server processes the commitment of the transaction, and when that's done it sends the result back to the client (if the client is still around to receive it - remember, it's none too reliable out there!). From the programmers' point of view, all this was hidden; they just gaily used the objects they knew and loved and the stuff they coded came to pass.

That's fine and dandy, but there must be some side effects, right? Well yes, from an administrative point of view there are. Relax, they're not too serious, but I'll tell you about them just in case you ever meet them in a dark alley somewhere.

Let's look at an example of a client invoking methods on three objects, A, B, and C (in that order), in a single transaction. Assume that these objects all run in different instances of the application server (clearly a poor design on all counts, but this is a Discovery Channel-style contrived example). At commit time, it's entirely possible that the three application servers have never directly communicated with one another. Certainly all the servers know of the existence of the transaction since it has touched them, but server A thinks it's the only participant - after all, it was the only participant the last time it was called. Only the client knows it has the full picture of the transaction. So the client chooses a server to handle the commit.

The current WebLogic Server implementation chooses the first server that was touched, A in this case, but as with all implementation details, that could change. Don't write code that relies on this behavior. Server A is sent the transaction object so now it, too, has the full picture of what the transaction is comprised of, and it can process the transaction's commitment. At this point, the commit processing is the same as for a transaction started within the application server; server A needs to tell servers B and C about the impending commitment. As you may already know from a previous article, the servers will need to trust one another (if you're not a regular reader, it serves you right - get the back issues!). There is, however, one subtle difference. Remember, servers A, B, and C may never have connected to each other before this moment, in which case they'll have to connect now. It's at this point that you'll get weird commitment failures (you guessed it, your old favorite HeuristicMixedException) if the servers can't contact each other. Whoever configured the TCP/IP network you're using better have allowed for this. Note that this is a static configuration error that can be caught only at runtime - a very good place for a timely reminder that you should do preproduction testing of your applications in as close a facsimile of the production system as you can get, even down to the network.

So, that's more WebLogic Server arcana unearthed for you. I'm back off to the beach now, just as soon as I catch up with that pork pie that's receding over the hilltop!