What is it that you are trying to exactly? Does thread 2 need to be
started only after a user app starts a job? Or could thread 2 be from a
background pool that is waiting for a job to run? Depending on what you
want to do, I think the answer is different.
On 02/04/2014 09:49 AM, Cheng Fang 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.
If you want to create a thread after the JTA transaction completes, you
could key that off of the Synchronization.afterCompletion(Status). See
http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron...
Thanks,
Cheng
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev