Armin Waibel <arminw <at> apache.org> writes: > > Hi, > > s guna wrote: > > > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > Armin > > thanks for the reply; I work with Vikram on this one. > > The real probelms we face is this; > > - we use OJB with sunone app server with db connection pool (max 64) to oracle > > - from time to time, we hit connections 64 and sunone instance hangs > > - and everyone says it is because suneone has used up all 64 connections > > - we use broker api with NOTPOOLED implementation > > as a side note, if you are using DataSource from appServer there is no > need to change the ConnectionFactory, because Datasources will never be > pooled by OJB. > > http://db.apache.org/ojb/docu/guides/connection.html#ConnectionFactory > > Is it possible to configure sunone pool to throw an exception when > connection pool is exhausted? This will prevent the appServer from being > hang-up. > > > - we do NOT use EJB; we do not use JTA; thsi is staright forward db query/save > > ok, then ignore the general intention of my previous post > > > app with lots of roudn trips; all we do is use ojb to get and put ; we get > > broker connections (our max is 100) and do saves and commits and then do > > broker.close > > - but connections are not getting released fast enough; they do get > > released > > if 64 is never hit > > so a PersistenceBroker (PB) leak (abandoned unclosed PB instances) is > excluded, did you close all used PB instances in finally blocks? > > > - therefore we thought we should put in EAGER-RELEASE which seemed to release > > connections immediately, but we ran into commit issues without automcomit > > setting > > as said in my previous post, don't use this property - it's evil! > If the used PB instance was not in tx, e.g. when doing a read query it > is possible to force OJB to release the used connection by calling > > broker.serviceConnectionManager().releaseConnection(); > > See last paragraph here > http://db.apache.org/ojb/docu/guides/connection.html #Can+I+directly+obtain+a%0A++++++++++++++++ > > But if you close the used PB instance immediately after use, there is no > need to do such a connection release by hand. > > > - from your message it seems like 1.x might do better; but when we tried, it > > required that policy files had to be changed for settings which we dont think our hosting partner would do; how can we move to 1.0x; > > We currently working on 1.1 (CVS head, early alpha-version not ready for > production) and on 1.0.2 (CVS "OJB_1_0_RELEASE" branch). Hope that we > release 1.0.2 in near future. > Which version of OJB are you using? Update from 1.0.1 to 1.0.2 will only > require to replace the OJB configuration files. > > > - or do u suggest that we use EAGER-RELEASE and autocommit and go on with it or should we conside subclassing the broker methods to force/release db conenction/ > > > > see above. > I recommend to use the default useAutoCommit setting '1' and change this > only for specific requirements. No subclassing needed you can release > connections using ConnectionManager (see above). > > > Sorry it is a long one...but this is what is happening. > > No problem, a detailed description of a problem is always welcome. > > Good luck in bug hunting > regards, > Armin
Hi Armin Thanks for the quick and incisive response as always! We're using a pretty old release of OJB. We're using OJB1.0RC4. Do you think it is OK to put in eager-release with this version of OJB, since we read that this was the version for which the eager-release was created. Of course we have eager-release in conjunction with autoCommit="0" as suggested in the OJB Deployment Guide. Also, if I understand what you're saying correctly, once I'm done using a broker, I can explicitly do a:broker.serviceConnectionManager().releaseConnection(); before I do a broker.close() thereby closing the connection and returning it to the app server connection pool? Thanks & Regards Vikram --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
