[wildfly-dev] Transaction synchronization between threads

[Jason Greene]

On Feb 4, 2014, at 10:28 AM, Cheng Fang <cfang at redhat.com> wrote:

> 
> 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.

The behavior I was basically describing is that in thread 1 you suspend the current transaction, start a new one, write the data and commit. After the commit has completed you fork thread 2 which will see thread 1’s write. This is semantically equivalent to the current behavior of your memory store, or even a future file system store. 

> 
> 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.

I think it depends on whether the batch client is viewed as a transactional participate, if it is then things get a lot more complicated. As an example, if you are using a file system store, or an in memory store, you need to actually have the ability to rollback if the transaction fails. This requires either developing an XAResource (like JMS has to do) or using a synchronization as a sloppy rollback mechanism. (In the JDBC case you don’t need it though, since JCA already manages this).

> 
> Cheng
>> 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
>> 
> 
> _______________________________________________
> 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