Hi Rick,
do you use OJB within enterprise beans or within servlets in managed environment?
> NullPointerExceptions and error messages saying > Root Cause as: Could not get connection. Wait timed-out.
Is there a stack trace showing some more detail?
> We are using OJB 1.0rc4 by the way. Is there something wrong there? > Should we shift to OJB 1.0 to solve this? >
Since rc4 a lot of work was done. The proxy/lazy handling stuff was completely reworked.
regards, Armin
Rick Banerjee wrote:
Hello Everyone!
I'm a newbie developer and I'm part of a team of developers working on a large project and using OJB for the first time.
We have some performance problems during load testing that needs sorting out for us to continue using OJB for our
persistance. We love OJB, so we really really want to solve this!
Here's the problem:
When we load the application with about 15 users we notice NullPointerExceptions and error messages saying Root Cause as: Could not get connection. Wait timed-out.
We notice all the NullPointerExceptions are being caused when we try to lazily materialize objects. We find that our application server connection pool has plenty of connections available, however OJB seems to ignore that and report that it can't get connections from pool.
Does anyone have any clue as to what is happening here? We can't control the way OJB does lazy loading but seems to be where this is failing. We are using OJB 1.0rc4 by the way. Is there something wrong there? Should we shift to OJB 1.0 to solve this?
Our application server is SunONE 7.0 running on a Windows 2000 box.
Please let me know if I should post some more details!
Thanks!
Rick
PS - Attached is a part of our OJB.properties file
#-------------------------------------------------------------------------------
# PersistenceBrokerFactory pool
#-------------------------------------------------------------------------------
# PersistenceBroker pool configuration
# This pool uses the jakarta-commons-pool api.
# There you can find things described in detail.
#
# maximum number of brokers that can be borrowed from the
# pool at one time. When non-positive, there is no limit.
maxActive=100
#
# controls the maximum number of brokers that can sit idle in the
# pool (per key) at any time. When non-positive, there is no limit
maxIdle=-1
#
# max time block to get broker instance from pool, after that exception #is thrown.
# When non-positive, block till last judgement
maxWait=2000
#
# indicates how long the eviction thread should sleep before "runs" of #examining
# idle objects. When non-positive, no eviction thread will be launched.
timeBetweenEvictionRunsMillis=-1
#
# specifies the minimum amount of time that an broker may sit idle
# in the pool before it is eligable for eviction due to idle time.
# When non-positive, no object will be dropped from the pool due
# to idle time alone (depends on timeBetweenEvictionRunsMillis > 0)
minEvictableIdleTimeMillis=1000000
#
# specifies the behaviour of the pool when broker capacity is
# exhausted (see maxActive above)
# 0 - fail
# 1 - block
# 2 - grow
whenExhaustedAction=2
#
#
#-------------------------------------------------------------------------
# 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.
ConnectionFactoryPooledImpl
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.
ConnectionFactoryNotPooledImpl
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.
ConnectionFactoryManagedImpl
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.
ConnectionFactoryDBCPImpl
#
#
#-------------------------------------------------------------------------------
# ConnectionManager
#-------------------------------------------------------------------------------
# The ConnectionManagerClass entry defines the ConnectionManager
implemementation to be used
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.
ConnectionManagerImpl
#
#
--------------------------------------------------------------------- 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]
