Re: New pooling (Long) [Was RE: Updates to the driver]

> 3) In a JNDI layer, it 'almost' makes sense for a the
> connection pool to ma

Oops, chopped this one off...

> 4) The property technique, where defaults are read that
> exist in the jar file,
> user can have their own property file, and users can set
> properties
> programmatically seems good to me. What objections do
> people have?

How about maybe a configuration item in the default properties file that
says 'I'm not going to read any further property files'... for the case
where the administrator bundles up a JAR with the settings he/she wants the
user to use and not override (on an OS or instance where the user cannot
simply modify the JAR that is or create another one to use).

> 5) Currently, if the username and/or password changes, I
> reset the entire
> pool. Is this bad? Should the ConnectionPoolDataSource
> contain multiple
> pools, each pool for each user/password combo? (With the
> ability flush a
> pool that is unused.) I figure I like my current
> implmentation, but I'm
> open to discussion

I like the idea of having separate named pools (I'm not sure if it makes
sense in this particular case, might do). So I can create a pool called
'read-only', one called 'dostuff-with-this-username' etc. It'd also be nice
to be able to specify different configs for each of the different pools
(with defaults) aka Poolman style. I've only recently started using Poolman
but it has some features I'd like to see in this beast like a 'soft
maximum', which if set means the driver will create connections above the
maximum if requested, but will close these connections when finished with
(as opposed to keeping them in the pool). The alternative is to wait until a
connection in the pool becomes available. There's a few other features that
would be nice.

> 7) Assuming this properties technique I have makes sense,
> should I move
> property retrieval into a more universally usable class
> in the utils
> directory? Or will no one else use it?

I think its a good idea to centralise all this functionality into one spot,
so if we change it later its easy enough to do. I normally create a
PropertyManager class that handles multiple property files, and also reloads
the property files when they change (low-priority thread that wakes up every
so often and checks the file modification time). You can also put useful
utility methods in this class like getIntegerProperty() etc and methods with
default values if the original key cannot be found.

Cheers,
Joe

***********Confidentiality/Limited Liability Statement***************

Have the latest business news and in depth analysis delivered to your
desktop. Subscribe to "Insights", Deloitte's fortnightly email
business bulletin . . .

http://www.deloitte.com.au/preferences/preference.asp

This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the
intended recipient of this message, you must not disseminate, copy or
take any action in reliance on it. If you have received this message
in error, please notify Deloitte Touche Tohmatsu immediately. Any
views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Deloitte.

The liability of Deloitte Touche Tohmatsu, is limited by, and to the
extent of, the Accountants' Scheme under the Professional Standards
Act 1994 (NSW).

The sender cannot guarantee that this email or any attachment to it is free of computer viruses or other conditions which may damage or
interfere with data, hardware or software with which it might be used. It is sent on the strict condition that the user carries out and relies
on its own procedures for ensuring that its use will not interfere with the recipients systems and the recipient assumes all risk of use and
absolves the sender of all responsibility for any consequence of its use.