Bug 5728 - Section 11 threading requirements for Job's and Step's should be relaxed
Section 11 threading requirements for Job's and Step's should be relaxed
Status: NEW
Product: jbatch
Classification: Unclassified
Component: SPEC
1
PC Linux
: P5 enhancement
: ---
Assigned To: ScottKurz
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-20 21:34 UTC by BrentDouglas
Modified: 2015-10-01 13:47 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description BrentDouglas 2014-01-20 21:34:40 UTC
Job's must have their before listeners and after listeners invoked in the same thread (11.3). Similarly partitioned Step's must have various parts invoked in the same thread as the thread as the Step started in (11.5,11.7).

Throughout these sections the main thread per section is referred to as 'Thread A' and it runs many of the items. This definition should be relaxed such that items run in 'Thread A' occur relative to other numbered items in the diagram with a relationship described as 'Happens before with the guarantee of only a single thread run in each item at a time'.

The current 'Thread A' definition means that we have a blocked thread for the duration of the job, and more blocked threads for the duration of each partitioned step, and really no convenient way to get around it. This proposal will not cause any issues with that approach but will allow other approaches, such as evented execution (which you could do now, but if 'Thread A' from one task got assigned another longer running task that the partitions, a completing task would have to wait for their 'Thread A' to be freed before resuming execution, so would not be very useful).


>     'Thread A' --->                       |-------------> 
>     'Px 1'         |-->
>     'Px 2'         |------>
>     'Other thing'  |--------------------->

FIG.1 If 'Thread A' spawns Px1 and Px2, but Thread A gets put back in the pool and gets assigned to 'Other thing' from some other job, 'Thread A' can't resume the first job until 'Other thing' finishes.


The only downside to this proposal is that clients will no longer be able to use ThreadLocal's, but realistically, they shouldn't have been doing that anyhow in managed code and should have been storing things in the Job/Step Context anyway.
Comment 1 ScottKurz 2014-01-20 22:49:58 UTC
Brent,

Thanks for writing that up.  It had crossed my mind that we might want to relax this.

Since I don't see this as a current spec or TCK ambiguity, I'm going to file this with a "future" tag, to look at for a possible future 1.1 release.  Hopefully we can get some other feedback too at that point.