Armin Waibel <arminw <at> apache.org> writes: > > Hi Vikram, > > > hmm, never heard about such a problem. Sounds as OJB does not > participate in the JTA-tx. > If you don't use EJB but you want to integrate OJB in the JTA-tx of the > appServer you need the same settings. In addition when using this > settings it is not allowed to use the tx demarcation of the OJB api's > (e.g. broker.beginTransaction, ...) only the use of JTA is allowed (e.g. > UserTransaction or container-managed- or bm-tx). > > Nevertheless in OJB 1.0.x release branch (branch OJB_1_0_RELEASE) I > fixed several issues in conjunction with use of OJB in managed > environments and updated the session bean examples (e.g. in RollbackBean > how to handle exceptions). > > > We have set the connection-descriptor property "eager-release" to "true" > > the property 'eager-release' was introduced as a workaround for problems > with older JBoss versions. > > http://db.apache.org/ojb/docu/guides/deployment.html#% 0A++++++++++++++++++++++++-N1022A > > > and > > the property "useAutoCommit" to "0". > > If you set "useAutoCommit" to "0" OJB doesn't try to change the > autoCommit state of the used connection. In managed environments it's > not allowed to change the autoCommit state of the used connection, so > this setting is mandatory. > > regards, > Armin > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 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 - we do NOT use EJB; we do not use JTA; thsi is staright forward db query/save 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 - therefore we thought we should put in EAGER-RELEASE which seemed to release connections immediately, but we ran into commit issues without automcomit setting - 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; - 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/
Sorry it is a long one...but this is what is happening. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
