Re: [wildfly-dev] Transaction synchronization between threads

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.