<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
In the JSR 352 batch specification there are some issues around
transactions with JCA. These issues would mainly be seen with JDBC
item readers/writers.<br>
<br>
Here is kind of a thought dump from a sit down I had with the JCA
team. If anyone has any opinions on how this should be handled let's
talk it out. I would imagine this is a fairly important issue as
generally speaking batch jobs will likely be legacy jobs and JDBC is
probably heavily used.<br>
<br>
<br>
<br>
<b>Batch Transactions with JCA</b><br>
<br>
<b>Problem:</b><br>
Batch requires that a Transaction.begin() and a Transaction.commit()
for each open, close and chunk processed. This causes connections
from JCA to potentially cross transactional boundaries.<br>
This requires that the JCA CachedConnectionManager (CCM) is
enabled for the resource in question (Jesper)<br>
<br>
<b>Transaction code should be written like:</b><br>
<tt>Connection c</tt><tt><br>
</tt><tt>Transaction.begin()</tt><tt><br>
</tt><tt>c = DataSource.getConnection()</tt><tt><br>
</tt><tt>c.close()</tt><tt><br>
</tt><tt>Transaction.commit()</tt><br>
<br>
<b>Chunk Processing process:</b><br>
<tt>Transaction.begin()</tt><tt><br>
</tt><tt>ItemReader.open()</tt><tt><br>
</tt><tt>ItemWriter.open()</tt><tt><br>
</tt><tt>Transaction.commit()</tt><tt><br>
</tt><tt><br>
</tt><tt>repeat until item reader returns null</tt><tt><br>
</tt><tt> Transaction.begin()</tt><tt><br>
</tt><tt> repeat-on-chunk</tt><tt><br>
</tt><tt> ItemReader.readItem()</tt><tt><br>
</tt><tt> ItemProcessor.processItem()</tt><tt><br>
</tt><tt> ItemWriter.writeItems</tt><tt><br>
</tt><tt> Transaction.commit()</tt><tt><br>
</tt><tt><br>
</tt><tt>Transaction.begin()</tt><tt><br>
</tt><tt>ItemReader.close()</tt><tt><br>
</tt><tt>ItemWriter.close()</tt><tt><br>
</tt><tt>Transaction.commit()</tt><br>
<br>
Where seen:<br>
<ul>
<li>No errors in 8.1+ </li>
<li>Upstream with the tracking set to true and exception is
thrown;
/subsystem=datasources/data-source=ExampleDS:write-attribute(name=tracking,
value=true)</li>
<li><a class="moz-txt-link-freetext"
href="https://gist.github.com/jamezp/cf39f92913425c83929f">https://gist.github.com/jamezp/cf39f92913425c83929f</a></li>
<ul>
<li>This shows where the connection was allocated that is
crossing the transaction boundary, and hence killed (Jesper)<br>
</li>
</ul>
</ul>
<br>
Questions:<br>
<ul>
<li>Will the tracking attribute be used often?</li>
<ul>
<li>The feature is meant to allow people to find where in their
code they are making assumptions that isn't true (Jesper)<br>
</li>
<ul>
<li>The corner case is just the "c.close()" call (Jesper)<br>
</li>
</ul>
</ul>
</ul>
<br>
<br>
<b>Possible Fixes:</b><br>
<ul>
<li>Leave batch as is. If the tracking attribute is set to true
exceptions will be thrown</li>
<ul>
<li>Remember that the underlying connection will be killed
(Jesper)</li>
</ul>
<li>Add a property to jBeret to use local (fake) transactions.
This is what we currently do and I feel it's just wrong.<br>
</li>
<li>Create a deployment descriptor (or possibly a property that
can be passed when starting the job) to allow different styles
for transactions</li>
</ul>
Example JBoss Way<br>
<tt>repeat until item reader returns null</tt><tt><br>
</tt><tt> Transaction.begin()</tt><tt><br>
</tt><tt> ItemReader.open()</tt><tt><br>
</tt><tt> ItemWriter.open()</tt><tt><br>
</tt><tt> repeat-on-chunk</tt><tt><br>
</tt><tt> ItemReader.readItem()</tt><tt><br>
</tt><tt> ItemProcessor.processItem()</tt><tt><br>
</tt><tt> ItemWriter.writeItems()</tt><tt><br>
</tt><tt> ItemReader.close()</tt><tt><br>
</tt><tt> ItemWriter.close()</tt><tt><br>
</tt><tt> Transaction.commit()</tt><br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
James R. Perkins
JBoss by Red Hat</pre>
</body>
</html>