[wildfly-dev] CMT Batch Puzzle (Was Re: [Transaction synchronization between threads])

[James R. Perkins]

Ignore me, I think I misunderstood what the issue was. I was thinking a 
long the lines of the job repository. Cheng explained it well here FWIW 
https://java.net/projects/jbatch/lists/public/archive/2014-02/message/1.

The RI doesn't appear to do any kind of suspend/resume of transactions. 
It just has it's own interface it uses and decides at runtime whether 
it's SE using non-JTA or grabs it from JNDI on the container for EE.

On 02/04/2014 02:10 PM, James R. Perkins wrote:
>
> On 02/04/2014 01:31 PM, Jason Greene wrote:
>> On Feb 4, 2014, at 1:42 PM, James R. Perkins <jperkins at redhat.com> 
>> wrote:
>>
>>> I don't see in the spec where it requires any kind of transaction 
>>> around a job repository. In fact the spec states "Note the 
>>> implementation of the job repository is outside the scope of this 
>>> specification.".
>>>
>>> The RI does have a JDBC repository, but it doesn't insert anything 
>>> into the tables in a transaction.
>>>
>>> If we're only seeing this in PostgreSQL and a workaround with 
>>> putting JobOperator.start() outside a transaction works, I would 
>>> suggest that's okay for now. I do agree it needs to be fixed, but we 
>>> might want to look at how we're handling transaction in JBeret as a 
>>> whole. The RI, not that I want to model anything after it, uses it's 
>>> own TransactionManagerAdapter. It might make sense for JBeret to use 
>>> a TransactionManager rather than a UserTransaction. Or put the 
>>> ownness on the SPI implementation of the BatchEnvironment to handle 
>>> the transactions.
>> Good points; and this brings me to my pathological batch puzzle. What 
>> does this code do:
>>
>> // Default gets transaction required
>> String doStuff() {
>>      long execID = jobOperator.start("simplejob", props);
>>      BatchStatus status = 
>> jobOperator.getJobExecution(execID).getBatchStatus()
>>      while (status != COMMITTED && status != FAILED && status != 
>> ABANDONED) {
>>          Thread.sleep(1000);
>>      }
>>      return status.toString();
>> }
> Cheng will probably be better at answering as I'm still learning the 
> spec better, but in general it will depend on what's defined in your 
> simplejob.xml. For a JDBC repository it will perform an DB operations 
> in a UserTransaction retrieved from the 
> org.jboss.as.txn.service.TxnServices. This is the same UT that would 
> be used for any transactions required in the batch job as well.
>
> For a in-memory repository, not transaction is used when updating the 
> repository.
>
> Now what really happens with that code though is if it reaches one of 
> those states fast enough you'll have an endless loop :P
>>
>> -- 
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>

-- 
James R. Perkins
Red Hat JBoss Middleware