Nope, actually I don't call the broker.close() method. Is it necessary? The example code didn't do that either and the JavaDoc says about the close() method: "Close this PersistenceBroker so that no further requests may be made on it. A PersistenceBroker instance can be used only until it is closed. Closing a PersistenceBroker might release it to the pool of available PersistenceBrokers, or might be garbage collected, at the option of the implementation. " So it might release the broker instance to the pool, not the connection. Or does it automatically closes the underlying Connection object?
I'll give a try anyway. -----Original Message----- From: Alexander Prozor [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 1:49 PM To: OJB Users List Subject: Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2 Do you call broker.clcse() method after storing/retriaving operations? >Hi, > >I have got a problem with using OJB RC3 on Weblogic 7.0 SP2. >In the Weblogic there's a connection pool and datasource set up. The OJB is >connecting to the database via this JNDI Datasource. No matter which >ConnectionFactoryClass I set in the OJB.properties, I always get a >connection leak error. Is it possible that the OJB doesn't close the >connection when it is not used anymore? > >I'd appreciate your help. >Thanks >Peter Bona > >the exception: >####<Aug 13, 2003 10:37:36 AM CEST> <Warning> <JDBC> < > <server-a> ><Finalizer> <kernel identity> <> <001074> <A JDBC pool connect ion leak was >detected. A Connection leak occurs when a connection obtained from >the pool was not closed explicitly by calling close() and then was disposed >by t >he garbage collector and returned to the connection pool. The following >stack tr >ace at create shows where the leaked connection was created. Stack trace at >con >nection create: > > at weblogic.jdbc.pool.Connection.<init>(Connection.java:62) > at >weblogic.jdbc.common.internal.RmiDataSource.getPoolConnectionObj(RmiD >ataSource.java:284) > at >weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiData >Source.java:252) > at >weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSour >ce.java:270) > at >org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newCo >nnectionFromDataSource(Unknown Source) > at >org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.looku >pConnection(Unknown Source) > at >org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookup >Connection(Unknown Source) > at >org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection > at >org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStateme >nt(Unknown Source) > at >org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown > Source) > at org.apache.ojb.broker.accesslayer.RsIterator.<init>(Unknown >Source) > at >org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unk >nown Source) > at >org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQue >ry(Unknown Source) > at >org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery >(Unknown Source) > at >org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery >(Unknown Source) > at >org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery >(Unknown Source) > at >org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery >(Unknown Source) > at >org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery >(Unknown Source) > at >org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB >yQuery(Unknown Source) > >The corresponding OJB.properties (part of it): >#-------------------------------------------------------------------------- - >------------- ># ConnectionFactory / Default ConnectionPool >#-------------------------------------------------------------------------- - >------------- ># The ConnectionFactoryClass entry determines which kind of >ConnectionFactory ># is to be used within org.apache.ojb as connection factory. ># A ConnectionFactory is responsible for creating ># JDBC Connections. Current version ships four implementations: ># ># 1. ConnectionFactoryNotPooledImpl ># No pooling, no playing around. ># Every connection request returns a new connection, ># every connection release close the connection. ># 2. ConnectionFactoryPooledImpl ># This implementation supports connection pooling. ># 3. ConnectionFactoryDBCPImpl ># Using the jakarta-DBCP api for connection management, support ># connection- and prepared statement-pooling, abandoned connection >handling. ># 4. ConnectionFactoryManagedImpl ># Connection factory for use within managed environments - e.g. JBoss. ># Every obtained DataSource was wrapped within OJB (and ignore ># e.g. con.commit() calls within OJB). ># Use this implementation e.g if you use Datasources from an application >server. ># ># Use the OJB performance tests to decide, which implementation is best for >you. ># The proper way of obtaining a connection is configured in ># JDBCConnectionDescriptor entries in the repository.xml file. ># If want a more fine grained control of each connection pool used by OJB, ># take a look at the repository.dtd, there was a possibility to override ># this default connection factory entry in each JDBCConnectionDescriptor. ># >#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactory P >ooledImpl >#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactory N >otPooledImpl >ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryM a >nagedImpl >#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactory D >BCPImpl > >--------------------------------------------------------------------- >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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
