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
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::::::::::::
--------------------------------------------------------------------- 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]
