Re: Re: [Proxool-developer] Bug 673073

[Andrew B. <ne...@my...>]

Hello all,

I will not quote any messages but I am going to comment few.

I would divide the problems on few groups:
1. Default pool behaviour
2. Work-arounds for JVMs that are not fully compatible or just obsolet
3. Pool customization

1. Default pool behaviour=20
Pool is an underlying subsystem or component serving in between of an exter=
nal data storage and application business logic (ABL). To be more precise=
 not the ABL itself but some abstraction layer that is responsible for da=
ta supplying. Normally, the ABL should not even suspect the existence of =
the pool. That's why the pool's behaviour should be transparent as much a=
s possible. As an example I would refer Garbage Collection. We can run it=
 in some particular cases but there is no need to call it in average case=
.=20

2. Work-arounds for JVMs that are not fully compatible or just obsolet
 The design of the pool should rely upon recent feature list to reduce code=
 overhead unless feature causes malfuction of the pool. If JVM is not ful=
ly compatible the work-around should be offered to simulate normal behavi=
our of the pool. It is bad idea to hardcode such work-arounds. It causes =
unpredictable code behaviour. In our case for all JVMs which doesn't exec=
ute shutdownHook should be used facade's method like shutdownPool() havin=
g empty signature. The name of such method must correspond to action sema=
ntics.=20

3. Pool customization
Since I have declared the default pool behaviour it is time to say how to c=
onfigure the pool. This topic is pretty wide and I will try to concentrat=
e just on few spots. These are:
=093.1 Pool parameter set=09
=09It includes all parameters impacting pool resource consuming in wide sen=
se of resource term. I mean how many connections are prototyped, how ofte=
n watchdog process is forked, etc.=20
=093.2 Pool diagnostics=20
=09This class of options doesn't impact resource consuming but let nest the=
 pool into custom framework. For example, currently the pool provides sta=
tistics with INFO log message type. In some cases it might be inconvenien=
t. May be it is possible to change I have not tried yet but indeed it mus=
t be changable.     
=09Of course the customization requires from user to use pool facade direct=
ly. Being a reusable component, the pool provides API to be managed. Use =
of the component is a matter of framework. In our case, Tomcat is sort of=
 framework. I would recom=D1=8Cend to make a wrapper around pool facade r=
einitializing the pool on getting servlet events. It's not responsibility=
 of the pool to know Tomcat or Tomouse being using it.

I am sorry for such a long essay however may be you fing it useful. If you =
have any questions or doubts you are welcome to [nm]ail me ;)

Regards,
Andrew.   
=09