AnsweredAssumed Answered

Refactor JobExecutor (ACT-34)

Question asked by ronald.van.kuijk on Jan 16, 2011
Latest reply on Oct 6, 2011 by bardioc
To continue the discussion from ACT-34 here seems better. The Jira should only contain conclusions (imo) or concrete directions.

The 'async workbeans' solution in WLS and Websphere seems 'older' than CommonJ. Strange then that it CommonJ refers to a withdrawn jsr and it mentiones that it is integrated in JSR-236. Which did not produces any results as far as I can see. The only reference to CommonJ is that it is input for the spec. From reading this CommonJ document it seems that one of the intentions was to get things decoupled from JCA (where the javax.resource… comes from). Ok, so much is clear now.

Basically I still hope it it still possible to share one container managed threadfactory (from a workmanager?) in multiple 'normal' ThreadPoolExecutors and that there is a similar thing for WLS (the most used appserver? In sold licences?)

Regarding using the timer fuctionality of either java.util or commonj, I have my doubts. Most of the timers will be relatively a long time from 'now'. So with lots of process instances, the behaviour will become difficult. The queue can be full but there could be timers in there which are beyond one that needs to be inserted now. Since timers are *not* concidered time critical, I think a normal queue where every x seconds query takes place to retrieve timers that are to be executed within x seconds is still a good option. The solution is then no different from normal queues.  Even putting the result of this query in a scheduled pool yields notthing I think. Well, maybe we could query every x seconds and query for timers in the period of 2*x seconds, so there is some overlap, but have the scheduled executor prevent the jobs to be executed to early. But that is an optimization…

Outcomes