Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Connection Pooling

Reply
Thread Tools

Connection Pooling

 
 
Chase Preuninger
Guest
Posts: n/a
 
      05-25-2008
What is the best way to create/get a database pool for a serious web
application?
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-25-2008
Chase Preuninger wrote:
> What is the best way to create/get a database pool for a serious web
> application?


Use the database connection pool capability in the app server.

Tomcat, JBoss, WebSphere, WebLogic etc. all supports it.

Arne
 
Reply With Quote
 
 
 
 
kuassi.mensah@gmail.com
Guest
Posts: n/a
 
      05-26-2008
On May 25, 1:49 pm, Arne Vajh°j <(E-Mail Removed)> wrote:
> Chase Preuninger wrote:
> > What is the best way to create/get a database pool for a serious web
> > application?

>
> Use the database connection pool capability in the app server.
>
> Tomcat, JBoss, WebSphere, WebLogic etc. all supports it.
>
> Arne


The problem with middle-tier connection pools is that they cannot span
JVMs or midlet0er instances. Oracle's Database Resident Connecton Pool
http://www.oracle.com/technology/tec...ity-ha-twp.pdf
solves this problem; unfortunately it is not (yet) exposed to Java
only PHP and Ruby/Rails (primarily because these are process based not
thread based).

Kuassi
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-27-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On May 25, 1:49 pm, Arne Vajh°j <(E-Mail Removed)> wrote:
>> Chase Preuninger wrote:
>>> What is the best way to create/get a database pool for a serious web
>>> application?

>> Use the database connection pool capability in the app server.
>>
>> Tomcat, JBoss, WebSphere, WebLogic etc. all supports it.

>
> The problem with middle-tier connection pools is that they cannot span
> JVMs or midlet0er instances.


That is not a problem. It is an advantage. Because interacting with pool
is then a local call.

> Oracle's Database Resident Connecton Pool
> http://www.oracle.com/technology/tec...ity-ha-twp.pdf
> solves this problem; unfortunately it is not (yet) exposed to Java
> only PHP and Ruby/Rails (primarily because these are process based not
> thread based).


That solution is used not because it is a better solution, but
because the traditional Java/.NET/C++ solution does not work with PHP.

You can use DRCP from Java.

http://www.oracle.com/technology/pub...g-pooling.html

describes how to specify the JDBC connection URL.

I think the interest from Java will be low. A local pool is faster. The
only benefit of a central pool is if the workload tend to be uneven
distributed among app servers - in that case a central pool will
use less resources.

Arne
 
Reply With Quote
 
kuassi.mensah@gmail.com
Guest
Posts: n/a
 
      05-27-2008
> > The problem with middle-tier connection pools is that they cannot span
> > JVMs or midlet0er instances.

>
> That is not a problem. It is an advantage. Because interacting with pool
> is then a local call.


The saving of local call to connection pool versus remote call to the
connection broker, is epsilon compared to the saving in terms of
resource brought by DRCP.

> > Oracle's Database Resident Connecton Pool
> >http://www.oracle.com/technology/tec...ity-ha-twp.pdf
> > solves this problem; unfortunately it is not (yet) exposed to Java
> > only PHP and Ruby/Rails (primarily because these are process based not
> > thread based).

>
> That solution is used not because it is a better solution, but
> because the traditional Java/.NET/C++ solution does not work with PHP.


Sure, unlike PHP and other dynamic languages, Java/.NET/C++ are not in
desperate need for a connection pool.

> You can use DRCP from Java.


Nope, the article you are referring to is wrong; and i am as we speak
asking the author to fix the misleading JDBC URL with DRCP.

> http://www.oracle.com/technology/pub...tabase-11g-top...
>
> describes how to specify the JDBC connection URL.
>
> I think the interest from Java will be low. A local pool is faster.


I will argue with this opinion. Think about a large web application
with thousands of middle-tier (let's assume 4000) with each their own
connection pool. Even if each middle-tier only allocate few
connections (let's settle for 5); you end up with 20,000 pre-allocated
connections!!! Assuming that only 50% of all connections are busy at
a point in time and that this is not uniform across all middle-tiers
(how could it be?); you will be wasting 10,000 connections.

Kuassi
 
Reply With Quote
 
joeNOSPAM@BEA.com
Guest
Posts: n/a
 
      05-27-2008
On May 27, 9:48 am, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> > > The problem with middle-tier connection pools is that they cannot span
> > > JVMs or midlet0er instances.

>
> > That is not a problem. It is an advantage. Because interacting with pool
> > is then a local call.

>
> The saving of local call to connection pool versus remote call to the
> connection broker, is epsilon compared to the saving in terms of
> resource brought by DRCP.
>
> > > Oracle's Database Resident Connecton Pool
> > >http://www.oracle.com/technology/tec...ity-ha-twp.pdf
> > > solves this problem; unfortunately it is not (yet) exposed to Java
> > > only PHP and Ruby/Rails (primarily because these are process based not
> > > thread based).

>
> > That solution is used not because it is a better solution, but
> > because the traditional Java/.NET/C++ solution does not work with PHP.

>
> Sure, unlike PHP and other dynamic languages, Java/.NET/C++ are not in
> desperate need for a connection pool.
>
> > You can use DRCP from Java.

>
> Nope, the article you are referring to is wrong; and i am as we speak
> asking the author to fix the misleading JDBC URL with DRCP.
>
> >http://www.oracle.com/technology/pub...tabase-11g-top...

>
> > describes how to specify the JDBC connection URL.

>
> > I think the interest from Java will be low. A local pool is faster.

>
> I will argue with this opinion. Think about a large web application
> with thousands of middle-tier (let's assume 4000) with each their own
> connection pool. Even if each middle-tier only allocate few
> connections (let's settle for 5); you end up with 20,000 pre-allocated
> connections!!! Assuming that only 50% of all connections are busy at
> a point in time and that this is not uniform across all middle-tiers
> (how could it be?); you will be wasting 10,000 connections.
>
> Kuassi


Hi Kuassi!

It seems to me that any DBMS-resident 'pooling' or any change that
makes a client's wait to get a new real connection shorter, would
be a good thing, and unless it imposes some new limit on the number
of connections, it seems it would be beneficial independently of
whether there is any pooling at the client side. For any client
architecture and distribution, it would be always important to
design a client-side pool to collect only the number of connections
actually needed by the client, so I would say that the problem of
over pre-allocation can be avoided, and indeed many pool allow a
discharge of unneeded connections after a time limit, so a good
client-side pool can maintain only what it needs.
Is a DBMS-resident connection 'pooling' a good answer for the
application profile you suggest, with 4000 middle-tier clients,
each averaging 10,000 in-use connections, and a random flux of
making up to 10,000 more as needed and closing them when not?
Joe
 
Reply With Quote
 
kuassi.mensah@gmail.com
Guest
Posts: n/a
 
      05-28-2008
> Hi Kuassi!
>
> It seems to me that any DBMS-resident 'pooling' or any change that
> makes a client's wait to get a new real connection shorter, would
> be a good thing, and unless it imposes some new limit on the number
> of connections, it seems it would be beneficial independently of
> whether there is any pooling at the client side. For any client
> architecture and distribution, it would be always important to
> design a client-side pool to collect only the number of connections
> actually needed by the client, so I would say that the problem of
> over pre-allocation can be avoided, and indeed many pool allow a
> discharge of unneeded connections after a time limit, so a good
> client-side pool can maintain only what it needs.
> Is a DBMS-resident connection 'pooling' a good answer for the
> application profile you suggest, with 4000 middle-tier clients,
> each averaging 10,000 in-use connections, and a random flux of
> making up to 10,000 more as needed and closing them when not?
> Joe


There is a socket creation (to the connection broker) during the very
first connection request from a client/middle-tier. When the
connection is returned to the pool, the socket is retained so that
subsequent connection requests do not pay that one-time socket
creation price.

DRCP does not impose a limit on the number of connections that a
client may request from the pool.

Yes, DRCP addresses the problem of over-allocation of database
connections (and the memory consumption) as a result of each client-
side middle-tier sizing its pool to avoid wait time. In a non-
centralized pooling (hundreds/thousands of middle-tier pools), there
is no way to meet the average in-use connections without over-sizing
or incurring expensive database connections creation/destruction.

Kuassi

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Connection Pooling, Dispose/Close/Using =?Utf-8?B?UGllcnNvbiBD?= ASP .Net 9 11-26-2008 02:58 PM
Connection pooling =?Utf-8?B?VmFtJHk=?= ASP .Net 1 11-24-2004 09:45 AM
Re: SqlConnection and connection pooling William \(Bill\) Vaughn ASP .Net 0 11-14-2003 07:27 PM
connection pooling error Chris Szabo ASP .Net 6 08-19-2003 07:19 PM
connection pooling Trevor Hartman ASP .Net 2 07-28-2003 07:58 PM



Advertisments