Peter Holditch

I have a rather deaf and rather elderly grandmother. She is a lovely woman and can spend hours telling tales - sometimes fascinating and sometimes... well, less fascinating - about times past.

Communication in the reverse direction can be a bit of a challenge - sometimes a raised voice will suffice, sometimes repeating what you want to say several times will do - and sometimes combining the two techniques together finally gets the message across. I swear that she finds it easier to hear things selectively, based on how convenient they are for her. This is a very clever - not to say mystical - filtering technique, to be sure, but still, as she says, what's the point of getting old if you don't get artful! When all else fails, and her ability to hear has apparently reached zero, there's nothing like a good old-fashioned piece of paper and pen (unless she's lost her glasses, but that's another story altogether). I'm sure you'll agree that my grandmother is very similar to a lot of software systems - in her day she was a woman ahead of her time, you know... Well, okay. Maybe you won't - so I'll explain what I mean...

Nearly any development that anyone ever does will involve creating a bit of new logic, and a lot of passing messages between existing systems. These existing systems are the ones that I think of as like my gran - some very elderly, and all esoteric and rather particular about how you communicate with them. Given this, it's generally a bad idea to build a new system by close coupling all the required elements in a point-to-point fashion. The resultant system would be extremely brittle and unreliable - a kind of giant, unpredictable hairball (imagine my gran and her bridge club all jointly completing a single bingo card). At the very best, all the communication logic would be surrounded by complex retry logic and be very difficult to understand.

That's why loose coupling is king - and reliable messaging often forms the backbone of loosely coupled systems within single organizations. It is for this reason that MOM systems like IBM's MQSeries and BEA WebLogic's own JMS messaging system are used so widely in real-world deployments. With their reliable messaging infrastructures, the sender of a message can know that eventually it will be delivered, whatever happens. They are the software equivalent of my writing notes to granny, and used to decouple systems can increase availability (at the expense of a whole operation not necessarily happening in real-time).

Whenever the subject of reliable message queuing is brought up, the subject of guaranteed once and once-only delivery is usually not far behind. It's all very well knowing for sure that a message will definitely be delivered from the point of view of the sender, but from the receiver's point of view it may be important to identify if you are receiving a message that you have actually already seen before. If my grandmother found a note reminding her to buy a pint of milk every day her fridge would soon overflow; and in the same way, if an increase in an employee's base salary was actioned multiple times because the message kept arriving at the HR system it would make for happy employees, but unhappy employers. So how do you make sure that you haven't seen a message before? Well, you need to keep a note of what messages you have received, and check each apparently new one against the list of ones you already received. So off you go to write some more code...

It's here that transactions come into the picture, and save you writing all that infrastructure logic. With an xa-compliant messaging server (for example, the one supplied out-of-the-box in WebLogic Server) the transaction manager can ensure once and once-only delivery. Most software systems, whatever the business logic, receive an instruction, process it, and update their state as a result of the processing. In the situation we're looking at now, the instruction will be received via a reliable queue. In nearly all systems, the persistent state is held in a database, most of which are xa compliant. By the rules of transactions, if you can receive the message, and do the database updates in a single JTA transaction, then either the message will be consumed and the updates will be persisted - if the transaction commits - or the message will be left on the queue and the persistent state will be unaltered - if the transaction aborts. It only takes a minute's thought to tell you that the transaction manager, in concert with the xa-compliant queuing system and database, has delivered once and once-only delivery to your application, so to speak. A great example of the use of infrastructure technology - you can count the lines of "once and once-only" logic that you now don't have to write and maintain because the transaction infrastructure did it for you out of the box. It's the equivalent of paying someone to take away gran's reminder notes at the supermarket checkout.

There is, however, a slight design wrinkle that needs to be borne in mind when using transactions like this. Imagine that the supermarket is out of milk. Our guy never gets to take away the reminder note, and gran will end up repeatedly making the trip to the supermarket only to find the milk cooler empty - her short- term memory really shows the signs of her age. Whilst walking up and down the road may keep her fit, there are certainly better uses of her time.

In systems implemented on computers - rather than grandmothers - this is known as the "poison message problem". Imagine our HR system receiving a message that Fred Smyth should receive a 10% pay raise - which couldn't be effected since Fred was actually laid off last month. If the transaction was rolled back as a result of this discovery, then the next thing that would happen is that the same instruction will be received again, and fail for the same reason. It's even less useful to keep computers fit in this way than it is my gran... Clearly this is a bad situation. The logic in the HR system should put this instruction in an error queue and flag the problem to a human to rectify in order that it can continue processing useful work, rather than choking on the (hopefully rare) error. On the other hand, of course, if the pay raise fails because the database is still restarting after a failure, then trying again in a couple of minutes may well be a good idea. In EJB terms, this illustrates the difference between System exceptions (database down) and Application exceptions (logic dictates that this cannot happen) and explains the difference in transactional behavior of the EJB container under these two conditions.

In general, you should code your applications so that they don't roll back transactions for business reasons, rather committing some kind of error notification. However, WebLogic Server's JMS implementation actually has two configurable settings to help with this kind of problem in the event that you don't code for it correctly. To cater to the technical failure case, a session can have an associated redelivery delay - a pause before an attempt will be made to redeliver it - this will hopefully allow the database time to recover (or whatever other transient error condition that exists to be corrected). To keep the logic failures from causing a permanent problem (or to prevent the system from wasting lots of time in the event of a long-term technical outage) there is also a redelivery limit. If a the system attempts to redeliver a message more than this (configurable). number of times, then it will not try again. You can configure whether the message should simply be discarded, or rather sent to an error queue (or topic) for administrative processing. For systems that are concerned about message ordering, WebLogic can also ensure that messages are redelivered in their original order too. I have never needed to give my gran more than one note at a time, so I have never tried that - and it's somewhat beyond the scope of this article.

So that's it for this month. I'm off now for a milky cup of cocoa and an audience with gran. I guarantee that will not happen once and once only.