Pool: Sharing eviction threads

["Roytman, Alex" <Ro...@peacetech.com>]

1. Reason
One eviction thread per pool is very expensive. In app server we can have tens 
or even hundreds of applications with several jdbc and other pools. It is 
imposibble to let each one to span a thread for eviction (I like this eviction 
feature very much) We clearly need to share eviction thread among pools.
In my opinion the best would be to use some sort of Timer class which will send 
notification to all pools which need eviction or any time driven maintenance 
done. In J2EE environment for example some sort of Timer can be looked up via JNDI 
and explicetly set to a pool during its configuration.

2. Proposal

Exposing a doEviction() on pool level will enable us to initiate eviction as we need and will be sufficient for to implement any type of scheduling. Hovewer I think Commons-Pool should provide some out of the box "default" eviction schediler like background daemon thread you use now. I think using java.util.Timer or similar techniques is preferable to using background daemon thread per pool primarily because it is external to pool and can be shared by multiple pools.
In case of java.util.Timer we would need: 
- Extend Evictor class from java.util.TimerTask 
- Add pool level method getEvictorTask() to return pool's evictor so it can be subscribed to listen for timer event. 

Evictor can implement several "Task" interfaces to support different schedulers i.e. ejb timer service etc. But I am not sure it should, because we are talking "default most commonly used" implementation and for other cases exposing doEviction() will be sufficient. 

Alex Roytman
mailto:roytmana@peacetech.com



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[Pool] Re: Sharing eviction threads

[Rodney Waldhoff <rw...@icarus.apache.org>]

One problem I see is that the java.util.Timer class was added in JDK 1.3.
Pool currently supports JDK 1.2 or higher.  Making Evictor extend
TimerTask would make it impossible to support 1.2 anymore.

Could we factor this such that this is an extension to pool (perhaps with
EvictorTask wrapping Evictor, rather than forcing Evictor to extends
TimerTask directly) than can be conditionally compiled in form or another?



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Sharing eviction threads

[Juozas Baliuka <ba...@centras.lt>]

+1 !!!
----- Original Message -----
From: "Roytman, Alex" <Ro...@peacetech.com>
To: <co...@jakarta.apache.org>
Sent: Thursday, October 31, 2002 5:15 PM
Subject: Pool: Sharing eviction threads


1. Reason
One eviction thread per pool is very expensive. In app server we can have
tens
or even hundreds of applications with several jdbc and other pools. It is
imposibble to let each one to span a thread for eviction (I like this
eviction
feature very much) We clearly need to share eviction thread among pools.
In my opinion the best would be to use some sort of Timer class which will
send
notification to all pools which need eviction or any time driven maintenance
done. In J2EE environment for example some sort of Timer can be looked up
via JNDI
and explicetly set to a pool during its configuration.

2. Proposal

Exposing a doEviction() on pool level will enable us to initiate eviction as
we need and will be sufficient for to implement any type of scheduling.
Hovewer I think Commons-Pool should provide some out of the box "default"
eviction schediler like background daemon thread you use now. I think using
java.util.Timer or similar techniques is preferable to using background
daemon thread per pool primarily because it is external to pool and can be
shared by multiple pools.
In case of java.util.Timer we would need:
- Extend Evictor class from java.util.TimerTask
- Add pool level method getEvictorTask() to return pool's evictor so it can
be subscribed to listen for timer event.

Evictor can implement several "Task" interfaces to support different
schedulers i.e. ejb timer service etc. But I am not sure it should, because
we are talking "default most commonly used" implementation and for other
cases exposing doEviction() will be sufficient.

Alex Roytman
mailto:roytmana@peacetech.com



--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>