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

[Jason Greene]

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();
}

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat