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