Re: Connection leak problem with OJB RC3 on Weblogic 7.0 SP2

[Alexander Prozor <ap...@isd.dp.ua>]

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.ConnectionFactoryP
>ooledImpl
>#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryN
>otPooledImpl
>ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryMa
>nagedImpl
>#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryD
>BCPImpl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org