Costas - many thanks. I've dropped the number of connections to 35 and things seem to be behaving. Your tool for finding leaks sounds very useful - please send it along.
- Bob ----- Original Message ----- From: "Costas Stergiou" <[EMAIL PROTECTED]> To: "Turbine Users List" <[EMAIL PROTECTED]> Sent: Thursday, March 14, 2002 2:43 AM Subject: Re: DB Pooling and Processes > Actually, the only way to close the connection is either if you issue > the DBConnection.close() method explicitly from your code or restart tomcat. > > But there should be no problem at all when reloading your app without > restarting tomcat: the Connection Pool code works fine. > > We have been using this code with oracle in a production db with thousands > of transactions per day and a total of >30 concurrent users (our call center > actually > uses a Turbine app with more than 1000 calls per day where the db supports > about > 100,000 customer records). I have never seen more > than 8 concurrent open connections (although TR.props settings is set to 30, > just > to be sure). I have made a small alteration to the code of Connection > Pooling so > I can get at any time the number of open connections and where they were > requested > from (through a vm screen). > I can send you this if you are interested (it has proven very usefult when > trying > to find leaks; in a big app the only way to do this is to track the stack > when the > connections are requested) > > Costas > > ----- Original Message ----- > From: "Bob Swerdlow" <[EMAIL PROTECTED]> > To: "Turbine Users List" <[EMAIL PROTECTED]> > Sent: Wednesday, March 13, 2002 9:07 PM > Subject: Re: DB Pooling and Processes > > > > Okay, thanks - I'll look at this. > > > > And, no, we're not using the OM, but rather one we spun ourselves (legacy > > stuff). > > > > Thanks for the help! > > > > ----- Original Message ----- > > From: "Phee, Martin J (Jump Tech)" <[EMAIL PROTECTED]> > > To: "'Turbine Users List'" <[EMAIL PROTECTED]> > > Sent: Wednesday, March 13, 2002 2:01 PM > > Subject: RE: DB Pooling and Processes > > > > > > > If you have your Oracle jars in the common/lib I believe you have to > > restart > > > tomcat to make sure everything gets released since they are shared > across > > > all apps. > > > > > > Take a look at your Turbine log to make sure that you don't see any > errors > > > say that your DBConnection was finalized before being returned to the > > pool. > > > When I started with turbine I noticed a few of them. Didn't realize I > > > needed to release the connection. Newbie thing for me. > > > > > > The OM is the object model created by the TDK or Torque. Depending on > > what > > > your using. > > > > > > -----Original Message----- > > > From: Bob Swerdlow [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, March 13, 2002 12:53 PM > > > To: Turbine Users List > > > Subject: Re: DB Pooling and Processes > > > > > > > > > Yes, we are using Tomcat and it did seem to let go of the processes when > I > > > restarted it. However, we are running more than one project under > Tomcat, > > > not all of which access the same database, so it is unfortunate to have > to > > > stop them all if we need to fix one. > > > > > > I've checked the code to ensure that the connections are being returned > > and > > > actually added logging so I can see that when they are created and > > released. > > > That all looks fine. > > > > > > Pardon my denseness - what's the OM? > > > > > > ----- Original Message ----- > > > From: "Phee, Martin J (Jump Tech)" <[EMAIL PROTECTED]> > > > To: "'Turbine Users List'" <[EMAIL PROTECTED]> > > > Sent: Wednesday, March 13, 2002 1:39 PM > > > Subject: RE: DB Pooling and Processes > > > > > > > > > > Are you using Tomcat? You might need to restart it also. Also, make > > sure > > > > you release your connections back to turbine, and close any statements > > you > > > > are using. Are you using the OM? > > > > > > > > -----Original Message----- > > > > From: Bob Swerdlow [mailto:[EMAIL PROTECTED]] > > > > Sent: Wednesday, March 13, 2002 12:30 PM > > > > To: Turbine Users List > > > > Subject: Re: DB Pooling and Processes > > > > > > > > > > > > Thanks, Ian. I'll get the number of processes and connections into > > line. > > > > > > > > Any idea how can I get rid of all the old connections when I reload > the > > > > project? > > > > > > > > Thanks, > > > > Bob > > > > > > > > ----- Original Message ----- > > > > From: "Ian Huynh" <[EMAIL PROTECTED]> > > > > To: "Turbine Users List" <[EMAIL PROTECTED]> > > > > Sent: Wednesday, March 13, 2002 1:12 PM > > > > Subject: RE: DB Pooling and Processes > > > > > > > > > > > > > Bob > > > > > I believe Oracle uses 1 process for each connection by default > unless > > > > > you've set up Oracle to use the MTS dispatcher. > > > > > > > > > > And also by default 50 is the default max process for Oracle. > > > > > You can control this file by editing your INIT*.ORA file typically > > found > > > > > in %ORACLE_HOME%\<YourSID>\pfile\init*.ora and look for the > > > > > entry > > > > > > > > > > PROCESSES=100 > > > > > > > > > > BTW, you also need to restart your Oracle server to pick up the new > > > value. > > > > > > > > > > Since connections are pooled (Don't know much about Turbine Pooling) > > but > > > > > in theory, if you app uses connection wisely, you shouldn't need too > > > many > > > > 'physical' > > > > > connections. BUt that entirely depends on your concurrent load and > > > length > > > > > of time a connection is used by a thread in your app. You need to > > load > > > > test your > > > > > app to find the right number. > > > > > > > > > > Also beware that Oracle also limits 300 open cursors by default. > This > > > > > is another area where most people also run into trouble. You can > > > > > change this param in your init*.ora file as well. If you need a > large > > > > > number of connections, chances are you probl. will run into this > limit > > > as > > > > well. > > > > > > > > > > open_cursors = 300 > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bob Swerdlow [mailto:[EMAIL PROTECTED]] > > > > > Sent: Wednesday, March 13, 2002 10:06 AM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: DB Pooling and Processes > > > > > > > > > > > > > > > Hi, y'all - > > > > > > > > > > Is there documentation somewhere about how to set up Oracle with > > Turbine > > > > DB > > > > > Pooling? > > > > > > > > > > We ran into a problem recently where we were getting "cannot get > > > > connection" > > > > > errors. I found that our TurbineProperties.Resources had: > > > > > > > > > > # The number of database connections to cache per ConnectionPool > > > > > # instance (specified per database). > > > > > database.default.maxConnections=3 > > > > > > > > > > Since the failure happend when our code was setting up 4 > connections, > > I > > > > knew > > > > > I had to change this. After a bit of web-snooping, I changed it to > > 100. > > > > > > > > > > Now we are getting this error: > > > > > ORA-00020: maximum number of processes (50) exceeded > > > > > > > > > > This actually happened after reloading the project a few times. > > > > > > > > > > So my questions are: > > > > > 1. What is an appropriate value for > database.default.maxConnections? > > > > This > > > > > will be a public web site with many concurrent users retrieving > pages > > > that > > > > > will access the database > > > > > 2. Do I need to coordinate the number of connections with the > number > > > of > > > > > Oracle processes? How do I control this in Oracle? > > > > > 3. Should reloading the project release all of the connections? > It > > > does > > > > > not seem to have done so, however, when I restarted Tomcat, those > > > > processes > > > > > seemed to go away. > > > > > 4. What else should I worry about? > > > > > > > > > > Thanks for your help! > > > > > > > > > > Bob Swerdlow > > > > > Chief Operating Officer > > > > > Transpose, LLC > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
