[wildfly-dev] Transaction synchronization between threads

[Stuart Douglas]

I would use a transaction synchronization, so you don't spawn the other
thread until the transaction is successfully committed.

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.

Stuart



On Tue, Feb 4, 2014 at 4:49 PM, Cheng Fang <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
> 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/f4eb0796/attachment.html