Resource pooling

Resource pooling is a common need among many software systems. There will be lots of questions once the high level design dectates that a particular resource/object needs to be pooled. People turn to container support, neighbhouring component implementations, open source implemenations etc.. before taking a solid decision because of its complexity in implementation.

When is pooling required?
Basic criteria for pooling is that — your system/design should support concurrency.

Objects need to be pooled
Objects a) whose creation is expensive in terms of resources, performance. b) who act as helpers — objects whose state is hardly matters and only performs operations on other objects.

java.util.concurrent package
Java 1.5 has a new package concurrent, whose basic moto is to support concurrent execution of tasks. It has a basic concept of Executor, which is responsible to execute task, a runnable object. There are concrete implementations of this Executor, namely ThreadPoolExecutor, ScheduledThtreadPoolExecutor.

The semantics of Executor is such way that, it can be implemented as a concurrent executor of tasks, or pool of some objects to perform task execution or both. Though Spring’s documentation refers Executor as a pool, I tend to differ on that — since it doesn’t have pool semantics.

Object pooling semantics:
In its simplest form,
1. An interface to the object to be pooled that define object’s life cycle methods (such as init(), destroy() etc..)
2. A Pool, that defines methods to
a) provide an object to the caller on request, [Various algorithms will be used to give best available object]
b) create the object
c) release object back to pool

I think above semantics should also be part of jdk (under java.util ?) to help ppl struggling with pools.

Should jvm provide this support?

In point-1 I mentioned above, every object to be pooled should have some sematics (init(), destroy()) in addition to regular object life cycle methods (constructor, finalize). Then the usual question arises as to what should I put in ctor vs init methods. Practically developers forget the constructor and push everything into init() method. (People almost forgot servlet’s constructor :) )

In addition to that, developer should know that he/has to release the object back to pool at appropriate time.

If jdk provides a marker interface, java.util.Poolable (sounds funny?) and provide few built-in Pools to choose from, it will be really easy to do object pooling.

Some thing like:

1 class MyObject implements Poolable{
2 //Do your usual stuff. Rest will be taken care for you.
3 }
Else, if developer wants to do his/her own pooling, we should still be able to provide that by providing above pooling semantics in jdk.

Life cycle of this object is managed by underlying pool and for the user, its just like any other object when it comes to life cycle. The key here is, it eliminates the burden of understanding the pooling implementation. Something worth trying on Kitchen sink language.

This is similar to Serializable and Externalizable interfaces for serialization support.