Trying to put JBossTS into perspective: the core

There have been a few comments on the forums recently asking how the various components within the JBossTS suite relate to one another. So I thought I'd try to put everything into context here so we can at least refer back to it if these questions come up again in the future. However, there's potentially a lot to say, so I'll split it across a few entries.

Note that these entry won't go into transaction basics: this is purely about the product and it's architecture.

You'll find a lot of this information in the various collatoral documents and presentations we've got. Plus, the documentation that ships with the product is very extensive and does cover this to one degree or another. So don't think this entry is a substitute to doing your homework.

Where to start? Well if you're interested in seeing the overall architecture we have a good description, but I think it's best to start at the beginning: ArjunaCore. As it's name suggests, this is the core of JBossTS: everything that needs transactional capabilities builds on this in one way or another. Using ArjunaCore you can get full transactional semantics for your applications in a local environment. You also get:

• Multi-threaded: transactions can have many threads operating within them concurrently.


• Nested transactions: transactions may be nested within one another. This allows for improved fault-tolerance the failure of a nested transaction does not automatically undo the work of the parent transaction) and modularity (nesting is transparent to applications, such that an object that requires transaction support can be constructed without a requirement that it must be invoked within a transaction: if it is then it's own transactions will simply be nested within the invokers and if it is not then the transactions will be top-level).


• Highly configurable: one of the key components to the performance of any transaction system is its log: the transaction log is used at many times during the lifetime of a transaction and the information it stores must be durable. Thus, disk I/O is a typical bottleneck to any transaction system. However, the usage patterns for transactions can also affect the log such that different log implementations perform better for different applications. Therefore, rather than provide a single log implementation, ArjunaCore allows different implementations to be plugged in at runtime to best suite the application requirements.


• Relaxation of properties across the ACID matrix: all of the ACID properties can be relaxed in a controlled manner. So, for example, the atomic nature of a traditional transaction can be modified to support OASIS BTP cohesive transactions. Furthermore, this means that the same transaction coordinator can be used to support many different transaction models. ArjunaCore provides the necessary support for BTP, but can also be used to support the various WS-CAF (or WS-T) transaction models.


• Optimised and performant: ArjunaCore has been developed in one form or another for over 15 years. In that time, it has been tuned and optimised to improve its performance.


• Adaptable failure recovery: arbitrary transactional resources can be enlisted with ArjunaCore transactions and recovery mechanisms can be provided that will be automatically driven by the failure recovery sub-system.


• No dependency on XA participants: it defines a neutral two-phase aware interface for transactional participants that does not mandate XA semantics.

Note, it is important to realize that ArjunaCore does not require any other software in order to run. It is a complete 100% pure Java implementation of a transaction system and does not require an ORB or application server in order to provide any of its functionality.

As a result of its flexibility, our core engine has been used within mobile transactions (it has a very small footprint and still runs on an HP Jornada 720), JMS implementations, JTS, JTA and Web Services transactions (supporting more than just ACID transactions).

Hopefully that's enough on ArjunaCore. Next entry I'll move "up" to our local JTA implementation.