Peter Holditch

Why are application servers so boring? I guess the answer to this question depends on your perspective. One man's boring commodity is another man's lifeblood. That observation alone would make for a rather short column, so we need another question... Who are these men, anyway?

Application servers are usually viewed from the perspective of an application developer. After all, J2EE is a lovely, thick set of specifications; they're very attractive to those of the developer persuasion, and it looks good if you can spell the acronyms correctly on your resume. All in all, not boring at all. A must-have commodity, but this wasn't always the case.

The advent of the application server reflects the increasing maturity of software engineering as a discipline, as it moves from art firmly to science. Despite this maturation, it amazes me when I run across developers who still delight in writing their own application infrastructure. "Not for me the straightjacket of a managed environment!" they exclaim, happily pulling a thread-pooling library from their pocket and inserting it into their next software magnum opus. This behavior reminds me of the book Round Ireland With a Fridge, whose intrepid author takes a fridge hitchhiking around Ireland. It makes for very amusing travel writing, but I would bank on it's not being the most effective mechanism of fridge transportation ever conceived.

Many application developers also find system administration boring. After all, that's the tedious part of an application's life; the exciting, creative part is over, and all that's left to do is sit and wait for the little red light to flash, whereupon you reboot the server. How boring is that?

Although it's a rhetorical question, this deserves an answer. If you own the budget for an application, then its operational lifetime is not at all boring. Far from it. Bear in mind that a useful application is likely to have a production lifetime of more than 10 years. Now, compare that with the development cycle, which in these days of application integration and component reuse typically comes in at six months or less. Imagine you could save $1 for every day of this period.... Now what's boring? If I can pocket the savings, I'll gladly take the 10-year operational lifetime and claim my $3,650 - the development cycle is hardly interesting at all.

This observation leads wise users to look beyond the licensing cost of a software product suite and shift their focus to the total cost of ownership over the solution's deployment life cycle. It's also what led those mature software engineer types to put away their customized thread-management libraries and take a long, hard look at application servers. Why? Well, every customized component of a runtime engine is another piece of infrastructure that needs care and feeding in deployment from a person trained in its idiosyncrasies. That's bad for the organization that has it deployed - what if their pet guru goes on vacation, or worse, falls under a bus? It's also bad for the gurus. All that knowledge they have to build up isn't transferable, so career prospects outside their favorite machine room or away from the beloved company pager (presumably an engraved gold pager, since they've been there so long) are limited. How much better were they application server administrators (or better still, WebLogic Server administrators!)?

What does this have to do with transactions? Well, it's all very sexy thinking about two-phase commits and ACID (if you're so inclined), but at the end of the day, transactions are about the integrity of your valuable business data. What most operations staff lose sleep over is losing valuable business data. For this reason, they need tools to monitor what's going on, to make sure all is healthy or - if the worst happens - to work it out when things start failing in production so they can get systems back on track with minimal fuss and data loss.

What tools does WebLogic Server provide to enable the system administrator to see what's happening and get things back on track after an outage? What administrative capabilities are provided by WebLogic Server with respect to transactions? Let's take a whistle-stop tour of what's in the box for the professional WebLogic Server administrator.

Server Administration
I always thought that in any distributed system it went without saying that the transaction logging and recovery services would be distributed. Apparently not, however, since one of WebLogic Server's major competitors centralizes the transaction log on a central administration server, providing a rather bizarre single point of failure. Rest assured, no such weaknesses are architected into WebLogic Server, so the first set of capabilities deals with managing distributed transaction logs. Every server instance that runs the JTA system has its own set of transaction logs. Ordinarily, they're cleared up by the server when they're no longer current, but if a server fails, decided transactions (written in the transaction logs) need to be rolled forward. This happens automatically if the associated WebLogic Server instance is restarted; if that's not possible, the logged transactions need to be recovered by another member of the cluster. Migrating the transaction recovery service from the failed server to a backup does this. In order for the recovery to be effected, the transaction log files must be visible to the backup server (since they are processed by the recovery process), so a dual ported disk, SAN, or other such technology must be in place. When the original server is rebooted the recovery service will gracefully return there, if the recovery has completed.

If the failure is too serious for an automatic recovery (head crash on the database, fire in the cabinet, etc.), an undocumented utility will dump out the contents of the transaction log in readable format. This could prove valuable for diagnosis of serious problems, and its details should be obtainable through BEA support.

Regular readers of this column will by now be true fanatics of the heuristically completed transaction. For such folk, two goodies are in the administrator's kit bag. First, the administrator can set a transaction abandonment timeout. If a transaction can't be completed before this limit is reached (maybe because a database isn't present), the server will give up trying. Since data may now be inconsistent, one of our beloved heuristic outcomes has occurred. But look on the bright side, the server didn't waste an infinite amount of energy trying to achieve the impossible. Of course, as in all these situations, the server will write a log record to record the failure.

The second place where heuristic outcomes may occur, and are logged, is in the heuristic log. If the server has imported a transaction from a foreign transaction manager (e.g., via OTS over IIOP), the server itself acts pretty much like an XA resource. This gives it the right in rare catastrophic situations (for example, after the transaction abandon timeout expires or if the XA resources participating in the WebLogic Server imported transaction throw heuristic exceptions) to make a heuristic decision. That is, unilaterally roll the transaction forward or back without the foreign transaction manager's say-so. When this happens, the event is recorded in the heuristic log file. This coexists with the tlog files, with a .heur in the filename before the .tlog extension. Look here when things go wrong in very convoluted deployments. (I recommend that you only look here after a stiff drink - in this kind of situation, you could be in for a long night!)

In less urgent times, the administrator can monitor transactions as they pass through the system. Clearly, since transactions should be of short duration, this will be an ever-changing snapshot of the system state, or it should be. One way an administrator can get early warning of impending disaster is if transactions start taking a long time to complete. For this reason, it's possible to sort the display of active transactions by how long they've been active. Application developers need to give the administrator guidelines as to how things should behave under normal conditions, but the sudden appearance of many long-duration transactions could be an early warning of a bigger problem.

While we're talking about the need for communication between developers and operators, we should review a few more features. WebLogic Server allows a name to be associated with each transaction; this can be done programmatically through the weblogic.transaction.Transaction interface or automatically by the EJB container for container-managed transactions. When the administrator is looking at the active transactions, or a dump of the transaction log, knowing the business operation that was being attempted in the scope of the transaction (developers: give them meaningful names!) could well give a starting point to fault investigations. For example, the account transfer transaction will touch two databases, the update address details will access the customer database, and so on.

WebLogic Server administrators can also set limits in the server: the maximum allowed number of concurrent transactions, the default transaction timeout, the abandonment timeout, and so on. In application server configuration in general, and in JTA in particular, it's important to use these limits to throttle the amount of work the application server will undertake. Bear in mind that for a deployment on any given set of hardware, there will be a physical limit to the possible throughput. By using administrative throttles to prevent the application server from trying to cross this physical threshold, you can ensure that your deployment will disappoint a few users while it quiets down from operating at the limits, rather than disappointing all the users together when the whole thing grinds unceremoniously to a halt due to lack of hardware resources to continue running.

Summary
Wow... I'm exhausted! I feel like that was a high-speed sprint though the foothills of a mountain of information. Inevitably, the techniques and nuances of management for any given application fall firmly outside the scope of a single, relatively short, generic column, but I hope this has provided a flavor of the facilities available and pointed you to where to go for more information.

In conclusion, I'd like to confirm that it's true. If admin is boring, then application servers are boring (and WebLogic Server is more boring than most) because while application servers do offer good prospects for the developer, their true value is realized when they're sitting in the background doing what they're best at - providing years of trouble-free operation to the systems they support.

References