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
