I am speaking of J2CA 1.5 WorkManager Aaron
On Tue, 16 Aug 2005, David Jencks wrote: > I haven't looked into the code here, but anyway... > > There are at least 2 work manager concepts > --j2ca 1.5 WorkManager, which includes stuff like transaction import. > This is not appropriate for use as a plain thread pool > --jsr ??? AFAIK unapproved WorkManager proposal, which is a reasonable > interface for a thread pool. IIRC someone planned to provide an > implementation of this but I haven't seen anything yet. > > Can you guys be a little more precise about which WorkManager concept > you are discussing? > > thanks > david jencks > > On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote: > > > I guess what I was saying was, let's pick one abstraction and go > > with it. It seems weird to have half the threads managed via thread > > pools, and half managed by work managers. If we agree that work > > managers > > are the way to get, we can use an adapter like you suggest to make > > OpenEJB > > work with a work manager, and then dispense with the thread pools in > > the > > server configuration. Is that OK with everyone? > > > > Aaron > > > > On Tue, 16 Aug 2005, Dain Sundstrom wrote: > >> I don't think it is a big deal to use a concurrent Executor, since it > >> is a subset of WorkManager. Executor has one method: > >> > >> public void execute(java.lang.Runnable command) > >> > >> which maps easily to: > >> > >> public void scheduleWork(Work work) > >> > >> Now, we just need WorkManagerExector and RunnableWork classes :) > >> > >> -dain > >> > >> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote: > >> > >>> Aaron, > >>> > >>> Ok I'm not an expert on the internals of J2EE > >>> architecture, but I'm going to give my .02$ here > >>> regardless and you can beat me up if/when you > >>> disagree: > >>> > >>> I think the standardization should be on the work > >>> manager api since it's purpose is to provide "...a > >>> concurrent programming API for use within managed > >>> environments on the Java TM platform, such as Servlets > >>> and EJBs" (I'm quoting directly from the paper > >>> Commonj-TimerAndWorkManager-Specification-v1.1). > >>> > >>> Using the work manager api also seems to make for a > >>> more sound architecture since the responsibility of > >>> task execution would be left to the api and would > >>> remove the requirement to maintain this logic in more > >>> than one place. > >>> > >>> Finally, it would seem appropriate that a future > >>> enhancement to the OpenEJB impl could involve the > >>> removal of the thread pools, replacing it with > >>> delegation of task execution directly to the work > >>> manager api; this is speculation and off topic, > >>> however, and so I won't continue. > >>> > >>> Thomas > >> > > > >
