[wildfly-dev] Transaction synchronization between threads

[Cheng Fang]

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.

Thanks,
Cheng
>
> Stuart
>
>
>
> On Tue, Feb 4, 2014 at 4:49 PM, Cheng Fang <cfang at redhat.com 
> <mailto:cfang at redhat.com>> wrote:
>
>     A jberet user reported JBERET-29
>     <https://issues.jboss.org/browse/JBERET-29> (Foreign key
>     constraint step_execution_jobexecutionid_fkey fails when using
>     Postgresql on WildFly, and we are trying to fix it by jberet
>     1.0.0.Final.  The problem happens when user app starts a job
>     within a transaction (e.g., CMT EJB), jberet inserts JobExecution
>     into database (thread 1 & transaction 1), and then spawn a
>     jberet-batch thread to run the job (thead 2 & transaction 2). 
>     Sometimes T2 tries to access db before T1 is committed, hence the
>     error reported by the user.
>
>     What's the common approach for solving this kind of problem?  I
>     suppose other WildFly components may also have this issue and
>     probably already solved.  Using transaction synchronization is a
>     cleaner solution than polling db, but I'm not sure about its full
>     implication.  Ideally, I don't want to use system level JTA API
>     like TransactionManager or Synchronization in jberet proper, but
>     probably we can implement it in WildFly jberet integration.
>
>     Thanks,
>     Cheng
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140204/eec80ad1/attachment-0001.html