[wildfly-dev] Transaction synchronization between threads

[Scott Marlow]

On 02/04/2014 04:16 PM, Jason Greene wrote:
>
> On Feb 4, 2014, at 3:13 PM, Jason Greene <jason.greene at redhat.com> wrote:
>
>>
>> On Feb 4, 2014, at 3:01 PM, James R. Perkins <jperkins at redhat.com> wrote:
>>
>>>
>>> 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 ;)
>>
>> That would be silly :)
Logically it would be the same as us suspending the TX/starting the job 
and resuming the TX.  I agree that its silly for the application to have 
to worry about suspending the tx, better if we handle this.

I'm just not sure which approach is better.  If the started job depends 
on application changes that aren't written to the database until the 
container managed transaction ends successfully, that could be a 
surprise to have the job start early.

I agree, that if the started job, doesn't have a dependency on the CMT 
ending, just suspendingTx/startingJb/resumingTx is best.

If the started job has a dependency on the CMT, could we have an 
extension property that specifies that (so we could defer starting the 
job when the tx completes successfully).

>
> Requiring a NOT_SUPPORTED method that is. It’s pretty easy for JBeret to isolate the transaction if it wanted to
>
> tx = TransactionManager.suspend()
> TransactionManager.begin()
> // write the record
> TransactionManager.commit()
> TransactionManager.resume(tx);
>
> --
> 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
>