I'm backing up what Max said about having a leak somewhere. We used to have
a lot of problems with pooling. We have about 50 database utility beans that
get a connection, perform action on the database then release the
connection.
We discovered that the leak came from one single method that didn't release
the connection. Once we corrected it, there was no more problems no matter
which scheme we use.
Raphaël
----- Original Message -----
From: "virupaksha" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 14, 2004 6:02 AM
Subject: Re: Database pool full.
> Dear Max,
>
> Yah, this problem occures after visiting some pages,
> to use #1 strategy, whether I need to do any changes in configuration or
is
> there any other way?
>
> Thanks for your suggestions & immediate response,
>
> Regards,
> viru
>
>
> ----- Original Message -----
> From: "Max Cooper" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 14, 2004 12:30 PM
> Subject: Re: Database pool full.
>
>
> > My guess is that you have a connection leak somewhere. Does this problem
> > start occurring immediately, or does it only show up after visiting a
> number
> > of pages in the site?
> >
> > Various db pools have different ways of dealing with no connections
being
> > available. Often, you can configure which strategy to use. Here are 3
> > different strategies:
> >
> > 1. Wait until a connection becomes available.
> > 2. Fail if no connections are available (i.e. return null or throw an
> > exception).
> > 3. Grow the pool temporarily if there are no free connections.
> >
> > It is clear from the errors you are getting that your pool is currently
> > using strategy #2. I like #1 the best, because it is less likely that
> > requests will fail under load. But, you must be sure that you don't have
> any
> > connection leaks, because the app will eventually hang if you have
> > connection leaks and use strategy #1. Strategy #3 works, but you can run
> > still run out of connections in the database itself, so it can start to
> act
> > like strategy #2. This is one aspect of connection pooling that
important
> to
> > consider when developing web apps.
> >
> > But, it seems likely that you have leaks somewhere. Some of your
requests
> > are probably not returning their connections to the pool. It could be
that
> > you have exceptions that are being thrown and not releasing the
> connection,
> > or it could just be that you have non-exception logic paths that don't
> > return the connections. Some combination of code reviews, debugging,
etc.
> is
> > needed to track them down.
> >
> > Another thing to watch out for is requests that require more than 1
> > simultaneous connection. For instance, consider the situation where you
> have
> > a pool of 30 connections, 15 request handler threads, and a request that
> > requires 3 connections. If 15 of those requests come in at once, and
each
> > request handler thread grabs 2 connections, you will have deadlock as
all
> > the request handler threads wait forever for a third db connection to
> become
> > available (assuming you are using pooling strategy #1 above). The
solution
> > to this problem is to make sure that you don't have any requests that
> > require more than one simultaneous connection, or at least that your db
> > connection pool has enough connections to survive a flood of connection
> > hungry requests (e.g. have a pool of 45 connections in the example
> scenario
> > described above -- 3 conn/req * 15 threads = 45 connections in the
pool).
> > This may seem unlikely, but it is a problem I have faced in a production
> > system (and it wasn't easy to track down!). Another lister here
suggested
> a
> > good technique for ensuring that none of your requests require more than
1
> > simultaneous connection -- test your app with a pool of 1 connections.
> >
> > -Max
> >
> > ----- Original Message -----
> > From: "virupaksha" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, January 13, 2004 7:14 PM
> > Subject: Database pool full.
> >
> >
> > Dear All,
> >
> > I am developing an application on resin-2.1.9 web server.
> > Connection to MYSQL Database is using JNDI. JNDI connection code is
> written
> > in a class called DBService.
> > I am instantiating DBService class where ever i need database connection
> and
> > getting connection using getConnection() method.
> >
> > when user start working on application, i m getting following errors,
> >
> > Class:DBService. Method:getConnection() cann't open connection with full
> > database pool(30)
> > Class:MonthReport. Method:SelectReportDetailNull() cann't open
connection
> > with full database pool(30)
> >
> > it sounds like database pool is full, Whether i need to increase the
pool
> > size or optimize code in DBService database connection class.
> >
> > for your reference below code performs database connection.
> >
> > --------------------------------------------------------------
> > public Connection getConnection()
> > {
> > java.sql.Connection con = null;
> > javax.sql.DataSource ds=null;
> >
> > try{
> >
> > Context initCtx = new InitialContext();
> > Context envCtx = (Context) initCtx.lookup("java:comp/env");
> > ds= (DataSource)envCtx.lookup("jdbc/training");
> > con = ds.getConnection();
> >
> > }catch(Exception e){
> > System.out.println("Class : DBService, Method :
> > getConnection()"+e.getMessage());
> > }
> > return con;
> >
> > }//end of getConnection method
>
> -------------------------------------------------------------------------
> >
> > Your advice will be great help to optimize my application.
> >
> > Thanks in advance.
> >
> > Regards,
> > Viru
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
