--------------Original Comment History----------------------------
Comment from = ScottKurz on 2015-10-06 19:21:23 +0000
I don't recall us discussing what's supposed to happen with JobOperator API calls from within an existing tran.
This is especially interesting in the case that the job repository is backed by something like a transactional database, (which of course is not required and just an impl detail).
I don't think we simply want to na�vely include the job repository DB in the caller's tran. On start(), you could insert a new job instance row on the original calling thread, start executing the job in another thread, and then have to roll back the new job instance later on, leaving things in what seems like an inconsistent state.
The "read" operations are also interesting. One could try to use a transactional scope to lock down the data (backed by a DB) across a series of "read" calls.
Not sure what to do or say here.
In the RI we did nothing and just allowed the tran scope to continue on in in spite of the above issues. In WebSphere Liberty, we went the complete opposite route and suspended the tran around every JobOperator API call.
I guess there's the option of saying that calling within an existing tran is impl-defined/undefined, (which is untestable, but could at least go into the spec).
I wonder if any other EE APIs deal with similar issues.
Thoughts?
Comment from = cf126330 on 2015-10-06 21:10:24 +0000
In JBeret, we take the middle-point approach: suspend any existing transaction for start() and restart(). For batch runtime to manage chunk transactions, it's critical to avoid any interference with any existing transactions. But for other operations, including read operations and short-lived action operations (stop, abandon), different applications may have different requirements, so we just leave the existing transaction as is.
I think it could benefit from some spec clarification, better than just saying undefined.
Originally opened as bug 7338 by ScottKurz
--------------Original Comment History---------------------------- Comment from = ScottKurz on 2015-10-06 19:21:23 +0000
I don't recall us discussing what's supposed to happen with JobOperator API calls from within an existing tran.
This is especially interesting in the case that the job repository is backed by something like a transactional database, (which of course is not required and just an impl detail).
I don't think we simply want to na�vely include the job repository DB in the caller's tran. On start(), you could insert a new job instance row on the original calling thread, start executing the job in another thread, and then have to roll back the new job instance later on, leaving things in what seems like an inconsistent state.
The "read" operations are also interesting. One could try to use a transactional scope to lock down the data (backed by a DB) across a series of "read" calls.
Not sure what to do or say here.
In the RI we did nothing and just allowed the tran scope to continue on in in spite of the above issues. In WebSphere Liberty, we went the complete opposite route and suspended the tran around every JobOperator API call.
I guess there's the option of saying that calling within an existing tran is impl-defined/undefined, (which is untestable, but could at least go into the spec).
I wonder if any other EE APIs deal with similar issues.
Thoughts?
Comment from = cf126330 on 2015-10-06 21:10:24 +0000
In JBeret, we take the middle-point approach: suspend any existing transaction for start() and restart(). For batch runtime to manage chunk transactions, it's critical to avoid any interference with any existing transactions. But for other operations, including read operations and short-lived action operations (stop, abandon), different applications may have different requirements, so we just leave the existing transaction as is.
I think it could benefit from some spec clarification, better than just saying undefined.