In Note 6 we explored the transactional behavior of a JCA MDB invoked by a JMS Adapter and orchestrating an Oracle JCA Adapter (a transactional end point) and a Batch Local File JCA Adapter (a non-transactional end point). In this Note let’s explore the issue of transactionality of a JCA Message-Driven Bean invoked by a non-transactional end point.
Let’s take the example from the “Java CAPS Basics: Implementing Common EAI Patterns Companion CD” book, ISBN: 0-13-713071-6, Chapter 11 “Scalability and Resilience”, Section 11.2 “Exception Handling”, subsection 11.2.1 “Exceptions in Java Collaborations”, 11.2.1.2 “Other Java Collaborations”. The book from which this section comes is available on the Companion CD. Let’s re-work this example using Java CAPS 6 JCA Adapters.
The example illustrates exception processing behaviour involving a Batch Inbound Adapter-triggered JCA Message-Driven Bean.
The Batch Inbound Adapter is designed to poll a directory for a file. When it finds a file that matches the name, or the name pattern, it immediately renames the fie by prepending a GUID to the original name then triggers the MDB and passes to it the original name of the file, the current name of the file and the directory in which the file was found. This behavior prevents other possible file pollers from getting hold of the file and gives the first comer exclusive access to the file. The MDB is designed to take the name of the file as given and rename the file to the original name with the suffix “~.in” appended, to indicate the file was read and processed. To do this the MDB will use the Batch Local File JCA Adapter’s capability to post-process the file by renaming or deleting it. To explore the transactional behavior the MDB will explicitly throw an exception after it renames the file.
The complete Note is available in 07BatcyhInboundTriggeredJCANonTransacionality.pdf.
