Re: [wildfly-dev] Transaction synchronization between threads

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(a)redhat.com <mailto:cfang@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev