On 02/04/2015 10:51 AM, Jesper Pedersen wrote:
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,
Right and this
*should* happen in the Item(Reader|Writer).close()
correct? Of course the user needs to ensure that happens, but it's
"safe" assuming they do right?
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.
I'm not necessarily
opposed to this, I'm just as concerned as I was :).
It might make sense to have another option for users that do need XA
resources and don't want to open/close them in each readItem().
James R. Perkins
JBoss by Red Hat