[wildfly-dev] Transaction synchronization between threads
Jason Greene
jason.greene at redhat.com
Tue Feb 4 10:11:39 EST 2014
Does the spec require that JobExecution be tied to a CMT transaction? It sounds like it should not be. If you were to make this into a local transaction that is committed before the call to create the job completes, then you shouldn’t have that problem.
On Feb 4, 2014, at 8:49 AM, Cheng Fang <cfang at redhat.com> wrote:
> A jberet user reported 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
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
More information about the wildfly-dev
mailing list