Sometimes an application's presentation layer must handle the coordination of multiple API layer method calls to complete a single transactional unit of work. In this article, Transaction strategies series author Mark Richards describes the Client Orchestration transaction strategy and explains how to implement it in the Java platform.
- Posted by: Frank Charles
- Posted on: May 26 2009 07:11 EDT
Mark Richard's article was an excellent read re: a client-side strategy for coordinating Java transactions. It is interesting to note that the strategy's implementation is 100% dependent on Java-specific services and protocols (e.g. EJB3, JOTM, JTA, Spring's transaction API, RMI/IIOP, etc). It might be interesting to describe the same strategy extended to include transaction service participants that are not necessarily Java dependent. E.g. WS-C, WS-AT, WS-BA based participants that would be client orchestrated via a JSR156-like API (superset of JTA) using SOAP for transaction context messages.
It is interesting to read Mark Richards papers on transaction strategies. But none of strategies is flexible enough regardless Client Orachestration or API based transaction stratedgy. Many cases we really need runtime information to decide to rollback or not even for the same method. What we need is transaction life cycle event interseptor. Just like EJB life cycle, we should be able to intercept transaction life cycle events such as: beforeStart, beforeCommit, beforeRollback postCommit, postRollback. These events can be intercepted to place codes for many related actions. For example, we can use preRollback or PostRollback to clean up non-transactional objects such as deleting files or clean up cache etc. PostCommit can use for send notifications etc. Chester