[concurrency-interest] Re: PooledLinkedBlockingQueue

Larry Riedel larryr@saturn.sdsu.edu
2 Nov 2004 16:50:51 -0000


> > I think it is particularly lame to have to create/destroy
> > an object for every time the pooled object is put/taken,
> > [...] I would not object to the idea of having a pool
> > specific object for each pooled object, one which has the
> > same lifetime as the pooled object, but has (for example)
> > a finalizer so the pooled object does not have to.
> 
> I guess I am not sure what you are saying here.  I am thinking
> that I would create something like:
> 
> public class PublicInterfaceObject {
> 	PooledObjectPool pool = ...;
> 	public static PooledObject getInstance(...) {
> 		PooledObject obj = pool.getInstance(...);
> 		return new PublicPooledObject(pool, obj);
> [...]
> public class PublicPooledObject {
> 	PooledObject delegate;
> 	PublicPooledObject( PooledObjectPool pool, PooledObject del ) {
> 		delegate = del;
> 	}
> 	private final void finalize() {
> 		pool.add(delegate);

That looks right as far as what I prefer not to do-- have to
create/destroy an object for each call to getInstance().  I
want to have a WeakReference to a pooled object, which gets
put in a ReferenceQueue for the pool manager after it is no
longer strongly reachable; when the pooled object shows up
in the ReferenceQueue, it gets reset and put back in the
pool; in the dotNET CLR I can call the ReRegisterForFinalize
to complete the resurrection; in Java/JVM, an object can
only become eligible for finalization once, so a particular
object instance will only get put into a ReferenceQueue once
during its lifetime.  By the way, I am not saying I think
this is a /clean/ way to achieve the end result of utilizing
the services of the garbage collector for tracking object
reachability without having it also control the lifecycle...
it is just /a/ way.


Larry