4:40 p.m.
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(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();
> }
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