Synchronized ConnectionPool access

Question

Is there a way to avoid ResourceExceptions when performing
more requests for database connections from the pool than
are currently available?
Is there a kind of synchronized access which forces callers
to wait until used connections are released?
Regards
Osman

Answer 1

Larry Presswood wrote:
The issue is that at least in 6.0 sp2 rp2 is that this resource exception is thrown
even when there are enough DBMS connections.
We have a situation where we have 75 connections set up and max
in use at the time of the resource exception is around 7-10??
There appears to be a bug in 6.0??Well, yes, as you describe it, it sounds like a bug, but there are many current and
past customers of 6.0, and connection pools are probably the single most
travelled code path in the J2EE APIs, so we might have heard of this sooner.
An optimally crafted application can get away with one pool connection per execute
thread. How many execute threads do you have, and on what sort of machine are
you running? How many connections in the pool? Please describe how your code
obtains pool connections, and how it closes them.
thanks,
Joe
>
>
Joseph Weinstein wrote:
osman vurgun wrote:
Is there a way to avoid ResourceExceptions when performing
more requests for database connections from the pool than
are currently available?
Is there a kind of synchronized access which forces callers
to wait until used connections are released?
Regards
OsmanHi. This is a frequently asked question. Some day we'll put the answer in our
docs. No, there's no way to allow a caller to wait for a pool connection,
and from the system point of view there shouldn't be. Any caller waiting
is tieing up one of the fixed number of execute threads in the server, which
could otherwise be running another server task that has all it's resources
to do it's work. Enough 'patient waiters' could freeze the server solid,
especially if all the pool connections were being held by jobs on the server's
run queue, but would never run to release these connections because
all the execute threads were being held by waiters.
It is the system's responsibility to quickly reject any excess work, above the
amount it can handle, so it can continue to do work. Any system that permits
itself to devote it's resources to non-productive work is open to denial-of-
service attacks (inadvertant or intentional).
The fundamental problem is too few resources (pool conections) for the
work load, and the correct response is to make the pool bigger. Optimally
designed applications only require the server to have one pool connection
per execute thread.
Lastly, the proper application response to a resource exception is not
to do a tight loop retrying, at least not in serverside code. That accomplishes
the same tieing up of an execute thread. The exception should go back to
the external client for a retry from there.
Joe