[wildfly-dev] Transactions in Batch (JSR 352)

James R. Perkins jperkins at redhat.com
Wed Feb 4 13:55:57 EST 2015


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?
>
>
> http://www.ironjacamar.org/doc/userguide/1.2/en-US/html/ch04.html#configuration_ironjacamar_leakpool 
>
>
> 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().
>
> Best regards,
>  Jesper
>

-- 
James R. Perkins
JBoss by Red Hat



More information about the wildfly-dev mailing list