Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: DBCP: Jdbc2PoolDataSource needs attention
Date: Mon, 11 Nov 2002 03:20:08 -0500
Message-ID: <450251B8E6DA1E4EAE9DA56C850B025C76B62B@ptint1.peacetech.com>
Thread-Topic: DBCP: Jdbc2PoolDataSource needs attention
Thread-Index: AcKJBZthau7FIiBOQ6S6s7cuk2YOuAAUi+PQ
From: "Roytman, Alex" <Roytmana@peacetech.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

John,=20

Using static map can be tricky as it makes things class loader =
dependent. If pool jars are shared among contexts it can cause jndi name =
collision - two contexts will not be able declare a DataSource with the =
same jndi name.

Due to urgent need I could not wait for existing version to be fixed and =
developed my own version.
I posted source code on the list several days ago. I has couple extra =
little things like shared eviction thread and I think it addresses =
several other issues with existing implementation, which I did not =
mention in my post. I intend to continue with my code (since I have =
already spent two days on it) and add few more features I think would be =
useful and I wonder if I should post it to this list.

Alex=20


-----Original Message-----
From: John McNally [mailto:jmcnally@collab.net]
Sent: Sunday, November 10, 2002 5:08 PM
To: Jakarta Commons Developers List
Subject: Re: DBCP: Jdbc2PoolDataSource needs attention


On Fri, 2002-11-01 at 10:04, Roytman, Alex wrote:
> Dear apache-commons developers,
>=20
> Jdbc2PoolDataSource is a very useful component however I believe it is =
not up to "release" quality yet
> While working with it I found some things I would like to improve or =
change.=20
> Please forgive me if I misunderstood certain things in =
Jdbc2PoolDataSource design as I could only spend limited time testing, =
debugging and reading its source
>=20
> 1. mutable poolable keys are very dangerous and lead to errors. One =
subtle error which rendered entire component useless in case of =
getConnection(username, password) was due to this error =
http://issues.apache.org/bugzilla/show_bug.cgi?id=3D13235
>=20

I have made the keys immutable.

> 2. new pool gets created for every different user =
getConnection(username, password). Also due to pool design if user wants =
eviction each pool will span an eviction thread which can easily bring =
any server to its knees. I think creating new pool for each user is =
related to ability to configure each user separately. My believe it is =
really not an objective because a) as much as possible in their projects =
people should use pools which are fully configured and do not use =
getConnection(username, password) but getConnection() instead and b) if =
they do need pool which caters for application where username/password =
is supplied by user for each session rather then configured in =
application this pool should have no reason to configure different users =
differently (as it has no prior knowledge of its users)
> Also for this kind of pool it is important to be efficient as number =
of users can be very high
> and we should be extra careful to survive programming mistakes or =
malicious users in this case
>=20

A new pool only gets created for each user that is configured with a
perUserMaxActive value and possibly other perUser values.  This might be
used to have a user that can write and a readOnly user, for example.=20
You state that separate DataSources should be setup for each of these.=20
I don't know enough cases to determine if that is the case, if others
agree, we can drop the per user configuration, but I would prefer to
keep unless given more definitive reasons it is bad. But it would not
effect the number of threads as the overall number of pools will be the
same in either case.

> 3. In current implementation once a pool for particular user/password =
got created and have some idle connection a user with INVALID password =
but right user name can grab connections from the pool (have not tested =
but it looks like it is the case)
>=20

I have fixed this.

> 4. failed connections get suck in active pool

I was not able to reproduce this, but if the mutable, poolable keys were
the problem, it should be fixed.  As soon as I get my changes into cvs
maybe you could repeat your tests?

>=20
> 5. Not sure why we need to keep a static map of all pools by =
datasource. J2EE environment will call jndi environment =
getObjectInstance() only once to create a pool and then the environment =
will keep the reference and will not call factory method on each object =
lookup but return previously created instance
>=20

Tomcat may do this, I do not know.  But I do not think a jndi service is
required to return the same instance to every lookup.  Is there a
specification that says J2EE containers will cache instances?  The jdbc
spec mentions use of static fields as a way to code around the fact that
there might be multiple instances which should be referring to the same
pool of connections.=20

john mcnally


--
To unsubscribe, e-mail:   =
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: =
<mailto:commons-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>