Re: pooled connection myth
From: David McDivitt (x12code-del_at_del-yahoo.com)
Date: 03/16/05
- Next message: David McDivitt: "Re: pooled connection myth"
- Previous message: Re_endian_miss_at_yahoo.com: "Newbie question: Formatting JSPs for different browser settings"
- In reply to: Malte: "Re: pooled connection myth"
- Next in thread: John C. Bollinger: "Re: pooled connection myth"
- Reply: John C. Bollinger: "Re: pooled connection myth"
- Reply: Virgil Green: "Re: pooled connection myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 16 Mar 2005 16:19:14 -0600
You said the magic words: gives back the connection to the pool. There is no
pool. Each time a connection is closed it is gone. To use a connection, a
new one must be instantiated from the driver with user name and password.
What you describe is part of the myth regarding pooled connections. When the
framework pools, it pools drivers only. In other words, all connections made
to your Oracle go through the same instance of the Oracle driver. If you had
Oracle, DB2, Sybase, and SQL Server for instance, connections would be
pooled with regard to the major data source, but individual connections
would not be pooled.
To modify your connection manager, try instantiating a connection object at
class level and after the first connection request, continue returning the
same connection object from the class level. That one connection object
should support multiple threads. Add a timer thread to the connection
manager to read a dummy table each sixty seconds, and if it fails, null the
connection, and recreate on the next request. Finally, put a close method on
the connection manager to stop the timer thread to be used when the app
server stops. This is connection pooling. Anything less is not connection
pooling.
Connection managers may cache the database user name and password so they
don't have to be fetched from resources each time a connection is needed,
and that saves time, but from what I've seen, connection managers
instantiate a new connection object each time one is requested. That is not
connection pooling.
>Subject: Re: pooled connection myth
>Date: Wed, 16 Mar 2005 22:31:45 +0100
>
>David McDivitt wrote:
>> I hope some people comment on my original posting concerning DB2 or pooled
>> connections in general. Anyway, since you have a singleton, why not return
>> the same connection to each caller? Why do you need 160 possible
>> connections? In my connection manager I return one out of three in a round
>> robin fashion. Another method exists to return a standalone connection for
>> times when transactions might be used or other modifications done to the
>> connection object.
>
>Hmm, the Singleton is for a getInstance of my class which wraps Oracle's
>driver. It is not for the connection. Sorry for being unclear on that.
>
>My Singleton returns the wrapper which has a getConnection() method
>which returns a connection from the pool. It also sports a
>releaseConnection() method that gives back the connection to the pool.
>
>I couldn't not possibly do with only three connections, as this would
>limit the number of concurrent users.
>
>Obviously, I could roll my own pool using a Vector or something similar,
>but for this project we opted for Oracle's implementation. I am happy to
>report that, so far, our class performs very well.
- Next message: David McDivitt: "Re: pooled connection myth"
- Previous message: Re_endian_miss_at_yahoo.com: "Newbie question: Formatting JSPs for different browser settings"
- In reply to: Malte: "Re: pooled connection myth"
- Next in thread: John C. Bollinger: "Re: pooled connection myth"
- Reply: John C. Bollinger: "Re: pooled connection myth"
- Reply: Virgil Green: "Re: pooled connection myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
