Re: pooled connection myth
From: Virgil Green (vjg_at_DESPAMobsydian.com)
Date: 03/17/05
- Next message: steve: "Re: New job and I want to change the world..."
- Previous message: Edwin Martin: "Re: Newbie question: Formatting JSPs for different browser settings"
- In reply to: David McDivitt: "Re: pooled connection myth"
- Next in thread: Lisa: "Re: pooled connection myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 17 Mar 2005 00:06:01 GMT
David McDivitt wrote:
> 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.
For the most part, I agree with John Bollinger. As I read your original
post, I found myself asking questions like "what framework?" and "what
getPooledConnection() method?".
I couldn't understand why you thought connections would be closed rather
than being returned to a pool to be reused later. Even if the connection you
are given supports a close() method, I'd expect it to be (as John described)
intercepted by whatever wrapper object was implementing the Connection
interface and treated as a "return to pool" operation instead.
In fact, I found my self asking "why is there a getPooledConnection() method
at all?" I wouldn't expect to ask specifically for a pooled connection. I'd
expect that whatever infrastructure was being used would have a class,
possibly a Singleton, that was responsible for handing out connections and
only that class would have knowledge of where the connection came from and
whether it was pooled. I'd expect to just call a getConnection() method and
not worry about anything other than "closing" it via a close method that the
supporting class would handle by doing a real close or by returning it to
the pool.
In other words, most of my code should be oblivious to whether pooling is
being used. It should just ask for connections and "close" them when
finished with them. The class that is handing out connections should be free
to change between pooled and non-pooled connections as needed. It might even
used pooled connections when they are available over an internal network
interface and then used non-pooled connections when another route has to be
used to establish a connection.
I have an application where we use a leased line for access to a remote
system, but we have internet access as an automatic (within my code)
failover if the leased line is down for some reason. I don't, but I might
pool connections when the leased line is up and simply hand out new
connections for each request when I have to hit the internet instead.
I think the "myth" you are describing is something that is specific to your
infrastructure and has little to do with traditional connection pooling in a
Java environment.
-- Virgil
- Next message: steve: "Re: New job and I want to change the world..."
- Previous message: Edwin Martin: "Re: Newbie question: Formatting JSPs for different browser settings"
- In reply to: David McDivitt: "Re: pooled connection myth"
- Next in thread: Lisa: "Re: pooled connection myth"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
