1:42 p.m.
On 02/04/2014 08:16 AM, Jason Greene wrote:
On Feb 4, 2014, at 9:56 AM, Cheng Fang <cfang(a)redhat.com>
wrote:
> On 2/4/14, 9:57 AM, Stuart Douglas wrote:
>> I would use a transaction synchronization, so you don't spawn the other
thread until the transaction is successfully committed.
>>
> yes, we could implement it in wildfly-batch integration module.
>> What does the spec say about transactions? If a job is create in a thread that is
part of a transaction and the transaction is rolled back should the job actually go ahead?
Common sense would suggest not.
> The transaction treatment in the batch spec is mostly around item processing, not
much on how it interacts with the transaction in the running environment. The only place
that it touches on Java EE environment is section 9.7 Transactionality:
>
> Chunk type check points are transactional. The batch runtime uses global transaction
mode on the Java EE platform and local transaction mode on the Java SE platform. Global
transaction timeout is configurable at step-level with a step-level property:
>
> Yes, I agree if the batch client side transaction is rolled back, the job execution
should not proceed. With the current jberet impl, the job execution in this case will
fail since the job repository is not in good state, like in the above bug. If we have
transaction syncrhonization in place, then the job will not start running till transaction
1 is committed.
There is a consistency problem here though. If you expect the client side to rollback on
transaction failure, then the in-memory job store should as well. IMO before committing to
such a big feature, I would recommend looking at what the RI does here. If the spec
doesn’t describe it, and the RI doesn’t do it, then we should avoid investing time on it
at least right now where we really need to get WF8 out the door.
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.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
Red Hat JBoss Middleware