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

On Feb 4, 2014, at 1:42 PM, James R. Perkins <jperkins(a)redhat.com&gt; 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