On 2/4/14, 10:11 AM, Jason Greene wrote:
Does the spec require that JobExecution be tied to a CMT transaction?
No.
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.
Are you saying with local transaction, it can access
uncommitted data
from another transaction? In this case, JobExecution is still not
committed when it's accessed via foreign key by transaction 2.
Inside WildFly, we just look up and use UserTransaction to demarcate all
transactions, and it seems a bit odd to use local transaction just for
this case. The batch spec does require the use of global transaction on
Java EE platform.
Cheng
On Feb 4, 2014, at 8:49 AM, Cheng Fang <cfang(a)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(a)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