geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: FW: ThreadPool GBean And WorkManager
Date Fri, 01 Jul 2005 18:07:54 GMT
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