Anatomy of a Transaction

In a typical web application, one single transaction can generate multiple log statements. It’s important to tie-up all log statements generated by that particular transaction. In case if there is a problem in that particular transaction, these log statements would go great way in diagnosing the problem. In a multi-threaded environment, several transactions are processed concurrently, without the capability to tie-up log statements to a pertaining transaction, it’s very hard to diagnose any problem. Here is a strategy to tie-up log statements of a particular transaction in a JEE web application.

Creating a Unique Id for every Transaction

One can create universally unique identifier using following Java API:


It would generate Id something like this: 580a3c56-4544-4a0e-a700-8387a2117c22

Since in a web application, there are multiple users interacting, it would be a great feature if all log statements pertaining to a particular user can also be tied up. If that user experience any problem, you can see all the activities generated by him in the application. One way to tie all the log statements to a particular user is to print the “jsessionid” cookie element. This jsessionid is unique to a user in a browser. Sample jsessionid would look something like this: 24579552F87D49B8B0841E51909ED669.

So Unique Id pattern would be:




This Id will not help to tied all the log statements to a particular transaction, but also all transactions to a particular user.

How to set this Unique Id in every log statement?

A Servlet Filter needs to be created, which would build the above unique Id and set it to MDC of your logging framework. Suppose if you are using Log4J, this unique Id would be set on org.apache.log4j.MDC

Here is a good tutorial on how to populate value in MDC and how to configure the layout, so that Unique Id can be printed on every log statement:

Traversing multiple applications

Sometimes one request can span across multiple applications in an enterprise. There could be a web application which would make a call to a SOA/middle-tier application, which can make a call to another application to service the user request. In such circumstances, it’s extremely critical that above generated Id is passed across all the applications. All applications that are involved in processing the request should make sure to log the Id in each log statement using the MDC (discussed in above section). If a user experiences a problem, grepping for the transaction id across application log files should be able to give insight where & why problem is happening.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: