I thought I would devote this month's column to a subject that appeared a while ago in the weblogic.developer.interest.transaction newsgroup on newsgroups.bea.com. As an opening comment, if you have never seen these newsgroups and you are a WebLogic developer, then go find them immediately! They're a mine of useful information, and a great place to get questions answered or collect opinions on design ideas or the like.

Plug over, what was the thread about? Well, the bit I'd like to write up went as follows...

Assume I have a successful transaction that has not yet been committed to the database, but the client has already been notified about its success. The client can start another transaction that tries to modify the same data (or a portion of it). It seems logical that a second transaction should not be able to succeed before the first is 'really' complete. So there should not be a case when there are two transactions that affect the same piece of data and overlap in time after being reported complete (i.e. in the AbandonTimeout interval).

The short answer to this is "yes," but since one-word articles aren't in vogue this season, I'd like to walk through this true statement and highlight the important parts.

An Everyday Story of Transactional Folk
So the first part... a transaction is started, some data is accessed, and the transaction is committed. This is normal enough, an everyday tale of transactional folk; bread and butter for the average J2EE application developer. Less obvious, but in fact no less bread and butter, is that the client could see a successful outcome to a commit call prior to all the database changes that made up the transaction being committed. From the transaction manager's point of view, once all the participants in a transaction acknowledge their ability to commit if asked (that is, reply "YES" to a prepare request) and the decision to commit implied by a unanimous set of yes votes is written to the transaction log, then the transaction is as good as complete. Okay, so maybe the soon-to-be-permanent changes to the data aren't yet visible to the outside world, but come what may, eventually they will be. At this point, therefore, the TM can respond affirmatively to the client's commit request so that the client can get on with the rest of its life. At some future time the commit will complete. Note the phrase "some future time" - I cannot be more specific than that.... The time to complete a transaction will be dependent on many factors - how fast are the networks, databases, and so on involved? How many participants did the transaction have? Will all the databases and the transaction manager remain up while the completion happens? In practice, completion could be nearly instantaneous, or it could take a very long time indeed. However, I already said that the client doesn't care - it's off minding its own business while the transaction manager takes care of this stuff.

Of course, to say that the client doesn't care is possibly an oversimplification, as pointed out in the newsgroup quote. Imagine that the client wants to alter the same piece of data twice. The transaction manager has told it that transaction1 is complete, so it goes ahead, starts transaction2, and does the second set of updates. If the transaction2 updates affect the same pieces of database as transaction1 then we may have a problem. If the commit is complete, then everything is fine and the second transaction can go ahead. If, however, transaction1 has been given the green light to commit, but completion hasn't happened, the data will probably still be locked on its behalf, so transaction2 will fail since it is trying to modify locked data. Here we have a timing window. Sometimes the app works, sometimes it doesn't. And guess what? The sometimes will vary. In the beginning of a deployment there might be only a few resources involved in the transaction, and the transactions most often complete serially. No problem shows up. Now imagine that the deployment got more complex, and the data got spread over more databases. The commit takes longer to complete, and suddenly code that apparently worked is broken more often than not. This could clearly be a debugging headache of an unpleasant kind, especially if you're not the guy that wrote the original code (or if you are, it's so long ago you forgot how it works).

So the moral of the story is simple - the whole two-phase transaction management idea assumes that the data being modified in any given transaction is independent of the data that was modified in the last one, or the data that will be modified in the next one. If you get unlucky and hit the same data twice accidentally, then exceptions get thrown, but that's fine because it should be an exceptional case. In practice, that's not a problem since online transaction processing (OLTP)-style applications tend to be like that - a call center where the operator deals with a different customer per call; an expenses application where an employee adds line items to an expense report one at a time; and so on. If, however, you find yourself designing an application that expects to repeatedly update the same piece of data, then put all the work related to it in a single transaction. This is one of the cases where a bigger transaction is better than a smaller one (the rule of thumb is usually that smaller is better).

Aliens Abducted My Data!
So, what does the AbandonTimeout interval have to do with this, I hear the observant among you cry. Well, conceptually very little. However, if for some reason WebLogic's transaction manager can't complete a transaction it has decided to commit (say aliens abducted one of the databases during the commit processing), then it won't keep banging its head against a wall forever. Periodically, the transaction manager retries the commit but if it still hasn't succeeded after the AbandonTimeout has been reached, it will give up and log its disappointment in the log (leaving a harassed human administrator to sort the situation out) This avoids wasting server resources to no good effect. For our completion timing discussion, however, it governs the maximum time a transaction will await completion. The default for this value is 24 hours (remember, I did say completion time could be long!).

So that's this month's article complete, more transactions next month. Until then, I'm off to Alpha Centauri to retrieve my database.