David Currie

Here’s my first post of a series looking at some of the new functionality in WebSphere Application Server Version 6.1 that has come out of the Hursley Development Lab, in particular in the area of the service integration bus.

One of the most of obvious change is the addition of a new persistence mechanism: the file store. In Version 6.0, the messaging engine data store used JDBC to store persistent messages and transactional data (amongst other things) in to a database. There were a couple of issues with this. Firstly, even for non-transactional, non-persistent messaging, it meant configuring a database and, secondly, the out-of-the-box performance with the default Cloudscape database was not great.

In Version 6.1, the default is to use a proprietary flat file in much the same way as WebSphere MQ. Although almost three times faster than using Cloudscape, the best performance can still be obtained by offloading processing to a remote DB2 instance. It may also be preferable to still use a database for other reasons such as high availability and backup and recovery.

Having posted on WebSphere Service Registry and Repository yesterday, I thought it was a little unfair that, despite being out for a while now, I haven’t mentioned Version 6.1 of WebSphere Application Server. Robby Peterson has a developerWorks article providing an overview of the new features so I shan’t list them all here. I will, however, pick out a few that I think are important/interesting and then blog again on some of the new functionality brought to you by my development colleagues in Hursley.

(more…)

I should know better having once worked in the WebSphere Application Server transactions development team but it is easy to assume that JTA maintains consistency throughout the lifetime of a transaction. In reality though, for a distributed transaction it is impossible to ensure that all resource managers commit at precisely the same moment. The result is that, between the first and last commit, the state of the different resources is inconsistent. This can be a particular problem if one of the changes taking place under the transaction is used to trigger further processing.

(more…)