geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas P. Fuller" <thomas.ful...@coherentlogic.com>
Subject Re: FW: ThreadPool GBean And WorkManager
Date Sat, 02 Jul 2005 04:43:37 GMT
With regard to #3.

Why not have both and make the threading api more or
less a configuration issue?

We should be able to decouple framework from the
specific api via an interface -- and this could be
handy down the road if something new becomes available
which has an advantage not present in the Oswego or
1.5  packages.

This same idea is expressed in point 4 below.

-- Thomas

--- Jeremy Boynes <jboynes@apache.org> wrote:

> Tyagi, Rahul wrote:
> > 
> > 
> > 
> > Thanks Thomas,
> > 
> > 
> > Sure you can contribute and thanks for
> volunteering. I am not sure, During inception of a
> project do we mail to dev mailing list or not?
> > 
> > I am currently looking for reusable components
> within Geronimo which can be of help while
> developing WorkManager API and its configuration. I
> liked idea of developing it as SPI and implement
> WorkManager as wrapper around that.
> > 
> > 
> > Prior to starting implementation we would need to
> see following things.
> > 1. Current threading infrastructure within
> Geronimo.
> 
> It is very distributed - one of this things I think
> it is important to 
> address.
> 
> The current J2CA WorkManager is in
> org.apache.geronimo.connector.work
> 
> Every Jetty connector wraps its own ThreadedServer
> which contains its 
> own Jetty ThreadPool. I think the Tomcat connector
> does the same thing.
> 
> OpenEJB has its own service model that use the
> DefaultThreadPool.
> 
> > 2. Configuration of components as GBean.
> 
> Let's define the interfaces and components first -
> wrapping them as 
> GBeans after should be easy.
> 
> > 3. Which threading API we would/may use, Currently
> Geronimo is using Doug's API, but we have to see
> whether we can use JDK 1.5 java.util.concurrent pkg
> or back port of that, For this discussion we need to
> socialize it with team.
> 
> We do not want to pre-req the JDK1.5. runtime at
> this time so everything 
> still needs to run on JDK1.4. Switching from the old
> concurrent API to 
> the backport now may make things easier when we do
> decide to pre-req 1.5 
> later.
> 
> 
> > 4. Should we use WorkManager for all work
> processing or use blend of ThreadPool and
> WorkManager.
> 
> I think the APIs emphasis should be on Work and
> having Work executed 
> rather than on the implementation mechanism (e.g. a
> ThreadPool). The 
> initiators here (web, ejb, connector, timer, ...)
> all have work that 
> needs to be done (such as a request) but do not need
> to know about how 
> it is being done (e.g. which thread is being used).
> 
> I do think we need to extend the basic model from
> JSR-237 with the 
> ability to classify the Work through metadata. This
> would be used by the 
> scheduler to select the mechanism used to perform
> it. For example, 
> certain requests could be dispatched using higher
> priority threads than 
> others based on application, static vs. dynamic, or
> other things 
> meaningful at the web level.
> 
> > 
> > 5. Do we need to provide transaction management
> for WorkManager threads.
> > 
> 
> I don't think we should automatically perform
> transaction demarcation 
> for managed threads - that should be left to the
> Work itself. However, 
> one concept we have is of a TransactionContext and
> to simplify Work 
> implementations we could say we will always bind an 
> UnspecifiedTransactionContext to the thread.
> 
> --
> Jeremy
> 


Mime
View raw message