Re: [wildfly-dev] Transaction synchronization between threads

On 02/04/2014 02:42 PM, James R. Perkins wrote: > > On 02/04/2014 08:16 AM, Jason Greene wrote: >> On Feb 4, 2014, at 9:56 AM, Cheng Fang <cfang(a)redhat.com&gt; wrote: >> >>> On 2/4/14, 9:57 AM, Stuart Douglas wrote: >>>> I would use a transaction synchronization, so you don't spawn the >>>> other thread until the transaction is successfully committed. >>>> >>> yes, we could implement it in wildfly-batch integration module. >>>> 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. >>> The transaction treatment in the batch spec is mostly around item >>> processing, not much on how it interacts with the transaction in >>> the running environment. The only place that it touches on Java EE >>> environment is section 9.7 Transactionality: >>> >>> Chunk type check points are transactional. The batch runtime uses >>> global transaction mode on the Java EE platform and local >>> transaction mode on the Java SE platform. Global transaction >>> timeout is configurable at step-level with a step-level property: >>> >>> Yes, I agree if the batch client side transaction is rolled back, >>> the job execution should not proceed. With the current jberet >>> impl, the job execution in this case will fail since the job >>> repository is not in good state, like in the above bug. If we have >>> transaction syncrhonization in place, then the job will not start >>> running till transaction 1 is committed. >> There is a consistency problem here though. If you expect the client >> side to rollback on transaction failure, then the in-memory job >> store should as well. IMO before committing to such a big feature, I >> would recommend looking at what the RI does here. If the spec >> doesn’t describe it, and the RI doesn’t do it, then we should avoid >> investing time on it at least right now where we really need to get >> WF8 out the door. > I don't see in the spec where it requires any kind of transaction around > a job repository. In fact the spec states "Note the implementation of > the job repository is outside the scope of this specification.". > > The RI does have a JDBC repository, but it doesn't insert anything into > the tables in a transaction. > > If we're only seeing this in PostgreSQL and a workaround with putting > JobOperator.start() outside a transaction works, I would suggest that's > okay for now. I do agree it needs to be fixed, but we might want to look > at how we're handling transaction in JBeret as a whole. The RI, not that > I want to model anything after it, uses it's own > TransactionManagerAdapter. It might make sense for JBeret to use a > TransactionManager rather than a UserTransaction. Or put the ownness on > the SPI implementation of the BatchEnvironment to handle the > transactions. Are you saying that the application should work around this by calling a different bean method that is marked NOT_SUPPORTED to facilitate suspending the JTA transaction?

>> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >