Some databases, like Oracle in particular, don't seem to allow you to set the maximum duration for transactions (hence locks). This implies that some applications (those that don't behave well) can be holding long-lived locks on your data. The result is that some data may become unavailable (even for days in one particular case I have seen!!!).

The solution? I am not sure about other products, but the Atomikos transaction libraries make sure that none of your applications can hold locks longer than the configured XA transaction timeout. Meaning: you get the benefit of ensured control and availability of your data. It's ironic really; many people believe that XA can block your data but as this case shows it is exactly the opposite!

Did you hear about Spring? In my opinion, it is going to play a big role in J2EE and simplifying Java programming. At least when it comes to transactional applications, things are much simpler than with EJB.

Have a look for yourself: TSS was kind enough to publish my presentation on Spring.

With the finalization and publication of Web Services Addressing 1.0 - Core (WS-A) the world of web services has changed drastically (or will do so in the near future).

The idea behind addressing is to allow non-HTTP transports as well as HTTP transports, and even a chain of transports before a message finally gets to its destination. This would mean that a SOAP request can be routed via different platforms (JMS, HTTP, SMTP to name a few) and still make it to its destination. This goes hand in hand with asynchronous SOAP… Another major idea in WS-A is to allow acknowledgements, replies and faults to be returned to other addresses different from the original sender of a SOAP request.

A major consequence is that once again, the JAX-RPC processing model has to be stretched to accomodate this new standard. To see why, let's consider what happens in a typical JAX-RPC service endpoint:

1. An incoming request message is received via HTTP.
2. One or more handlers (intermediaries) are allowed to pre-process the message (mainly its headers).
3. The service implementation gets the message to do the real (business) part of the job and generates a reponse (if applicable).
4. One or more handlers get to post-process the response.
5. The HTTP conversation is terminated by sending an acknowledgement (with or without a response message).

This is almost inherently a synchronous request/reply paradigm, and things like returning a reply to a different address become very cumbersome: this has to be done in a handler that shortcuts the reponse chain and sends the SOAP message somewhere else instead…

Clustering and Load Balancing in Tomcat 5, Part 1 by Srini Penchikala -- The latest version of Tomcat provides clustering and load balancing capabilities for scalable, highly available systems. In part one of this series, Srini Penchikala looks at architectural factors to consider in such a system and how Tomcat implements them.