[wildfly-dev] Transaction synchronization between threads

[James R. Perkins]

On 02/04/2014 12:40 PM, Scott Marlow wrote:
> 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 at redhat.com> 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?
No I'm just saying they need to invoke the JobOperator.start() outside a 
transaction. At least from my understand on the JIRA that seems to 
workaround the issue. I will admit to not fully looking into this in 
detail though ;)

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

-- 
James R. Perkins
Red Hat JBoss Middleware