On 02/04/2015 01:42 PM, James R. Perkins wrote:
I'm retracting my email due to my misunderstanding. It's
likely most
item readers will not need a JTA data source. Therefore if you use a
non-JTA data source you can cache the connection for the readItem()
method. Any XA resources need to be opened and closed within the scope
of a single transaction. For example ItemWriter.writeItems(List<Object>
items) the XA resource must be opened and closed within this method and
NOT in the ItemWriter.open() and ItemWriter.close() methods.
In other words, there are no changes needed. It just needs to be noted
one should not cache an XA data source in the open method and attempt to
reuse it later.
Just remember that any non-transactional resources (NoTransaction) needs
an explicit .close() in order to be returned to the connection pool.
Otherwise you will out of connections fast ;) Scenarios like this can be
investigated using the IronJacamar leak detector pool,
http://www.ironjacamar.org/doc/userguide/1.2/en-US/html/ch04.html#configu...
since there is no transactional boundary to do the check on.
Batch is still a bit up in the air IMHO, and the container is counting
on the user to do the right thing. Which we all know doesn't always
happen. So, I think it is a good idea to explore different transactional
models looking at existing batch frameworks.
Best regards,
Jesper