That would be nice to have. Does it show the number of connections by pool? I have three or four different database connection with my app.
-----Original Message----- From: Costas Stergiou [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 1:44 AM To: Turbine Users List 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]>
