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

[James R. Perkins]

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