Hi Armin,
You can find the OJB.properties file below.
We are using v. 0.9.8, not 0.9.7, my mistake. Sorry for the confusion.
We use a datasource from the app server, configured in the
repository.xml file as follows:
<descriptor-repository version="0.9.8"
isolation-level="read-uncommitted">
<!-- The Default JDBC Connection. If a class-descriptor does not specify
its own JDBC Connection,
the Connection specified here will be used. -->
<jdbc-connection-descriptor
platform="Oracle"
jdbc-level="2.0"
jndi-datasource-name="jdbc/oracle"
username="some_db_user_name"
password="some_db_password"
/>
...
BTW, we tried to drastically increase the max number of database
connections configured for the datasource, but that does not seem to
make any difference. When the stress test runs, it gradually increases
the number of clients, each client firing the request every five
seconds. The application virtually stops responding when the number of
users approaches 30. For testing purposes, the query code is called
directly from a servlet, bypassing the layer of EJB session beans we
have in our architecture. Again, this does not influence the outcome of
the test.
Best regards, Jeroen
The OJB.properties looks like this:
===================================================
# OJB.properties -- configuration of the OJB runtime environment
# Version: 0.9.8
# (c) 2001, 2002, Apache Software Foundation
# Author: Thomas Mahler and many others
#
#----------------------------------------------------------------------------------------
# Default repository file
#----------------------------------------------------------------------------------------
# The repositoryFile entry tells OJB to use this file as as its standard
mapping
# repository. The file is looked up from the classpath.
#
repositoryFile=repository.xml
#
# If the useSerializedRepository entry is set to true, OJB tries to load
a
# serialized version of the repository for performance reasons.
# if set to false, OJB always loads the xml file
useSerializedRepository=false
#
#
#----------------------------------------------------------------------------------------
# OJB C/S mode
#----------------------------------------------------------------------------------------
#
# The useServer entry determines if OJB runs in single VM or in
client/server
# mode. The default value "false" launches single VM mode
#useServer=true
useServer=false
#
# The BokerServers entry is only evaluated if useServer=true.
# it declares a list of servers with their respective ports
# on that OJB PersistenceBrokerServer processes are running.
# The entries must be separated by commas.
# BrokerServers=stella\:2001,luna\:2001
BrokerServers=localhost\:2001
#
# The ServerThreadCount entry tells the PersistenceBrokerServer
# how many worker threads have to be started initially.
ServerThreadCount=10
#
# The BrokerPoolSize entry defines the number of PersistenceBrokers
# that reside in the BrokerPool of the PersistenceBrokerServer
BrokerPoolSize=10
#
# The UseCompression flag defines if GZIP compression should be used
# to compress the C/S coomunication
UseCompression=false
#UseCompression=true
#
#----------------------------------------------------------------------------------------
# PersistenceBrokerFactory / PersistenceBroker
#----------------------------------------------------------------------------------------
#
# The PersistenceBrokerFactoryClass entry decides which concrete
# PersistenceBrokerFactory implemention is to be used.
# Use this by for non-managed environments:
PersistenceBrokerFactoryClass=org.apache.ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl
#
# The PersistenceBrokerClass entry decides which concrete
PersistenceBroker
# implementation is to be served by the PersistenceBrokerFactory.
# This is the singlevm implementation:
PersistenceBrokerClass=org.apache.ojb.broker.singlevm.PersistenceBrokerImpl
#
#
#----------------------------------------------------------------------------------------
# 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=60000
#
# 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=60000
#
# 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 DEFAULT connection factory.
# A ConnectionFactory is responsible for creating
# JDBC Connections. Current version ships three 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.
# 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
#
# Specifies maximum number of connections that can be borrowed from a
# connection pool at one time. When non-positive, there is no limit.
# If want a more fine grained control of each connection pool used by
OJB,
# take a look at the repository.dtd.
maxConnectionsInPool=21
#
# Here you can set how OJB uses the autoCommit state of the used
connections. The default
# mode was 1. When using mode 0 or 2 with the PB-api, you must use PB
transaction demarcation
# 0 - OJB ignores the autoCommit setting of the connection and do not
try to change it.
# This mode could be helpfully if the connection don't let you set
the autoCommit state.
# (e.g. using datasources from application server)
# 1 - set autoCommit explicit 'true' when connection was created and
temporary
# set to 'false' when necessary.
# 2 - set autoCommit explicit 'false' when connection was created.
useAutoCommit=0
#
# if true, exceptions caused by setting autocommit state, will be
ignored
ignoreAutoCommitExceptions=false
#
#
#----------------------------------------------------------------------------------------
# SqlGenerator
#----------------------------------------------------------------------------------------
#
# The SqlGeneratorClass entry defines the SqlGenerator implemementation
to be used
SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
#
#
#----------------------------------------------------------------------------------------
# SequenceManager
#----------------------------------------------------------------------------------------
#
# The SequenceManagerClass entry determines the SequenceManager to be
used
# choose one of the implementations:
#----------------------------------
# 1. SequenceManagerHiLoImpl
# High/Low sequence manager implementation
# 2. SequenceManagerHiLoContinuousImpl
# High/Low sequence manager implementation
# generates continuous id's during runtime
# 3. SequenceManagerInMemoryImpl
# InMemory-sequence manager generates continuous id's during runtime
# This is the fastest standard sequence manager implementation, but
# has some Limitations:
# - do not use in client/server mode
# - do not use in clustered environments
# - do not use if other entities generate id's for objects
#
# H/L sequence manager implementation
SequenceManagerClass=org.apache.ojb.broker.util.sequence.SequenceManagerHiLoImpl
#
# H/L sequence manager generates continuous id's during runtime
#SequenceManagerClass=org.apache.ojb.broker.util.sequence.SequenceManagerHiLoContinuousImpl
#
# The SequenceManagerGrabSize entry determines the number IDs allocated
# within each sequence.
SequenceManagerGrabSize=1
#
# Specifies wether IDs should be unique for each id-name (so IDs would
be
# unique over all classes that use "oid" for their id and unique over
all
# classes that use "articleID" for their id, but not for the union of
those
# (so there could be an oid 4 and an articleID 4). This mode interacts
very
# badly with legacy data, as it doesn't try to find the highest used ID
over
# all classes, but only for those that are first accessed. This
parameter is
# useful only if you use one of the H/L sequence manager
implementations.
#SequenceManagerGlobalIDs=true
SequenceManagerGlobalIDs=false
#
# Here you can induce the sequence manager to use a
# different as the default repository to generate sequences
# (if using org.apache.ojb.broker.util.sequence.SequenceManagerHiLoImpl
# or
org.apache.ojb.broker.util.sequence.SequenceManagerHiLoContinuousImpl).
# The used class descriptor could be
# found under 'org.apache.ojb.broker.util.sequence.HighLowSequence' in
# repository_internal.xml.
# When running the OJB sequence manager in an j2ee environment with
# declarative or programmatic transactions it is advisable to separate
# the sequence generation using it's own non-transactional
# jdbc-connection/datasource.
#SequenceManagerRepository=repositorySeq.xml
#
#
#----------------------------------------------------------------------------------------
# Object cache
#----------------------------------------------------------------------------------------
# The ObjectCacheClass entry tells OJB which concrete instance Cache
# implementation is to be used.
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
#
#
#----------------------------------------------------------------------------------------
# Locking
#----------------------------------------------------------------------------------------
#
# The LockManagerClass entry tells OJB which concrete LockManager
# implementation is to be used.
LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
#
# The LockMapClass entry tells OJB which concrete LockMap
# implementation is to be used.
# If OJB is running in servermode it is recommended to use the
# PersistentLockMapImpl. It guarantees to provide Lockamanagement across
# multiple client JVMs.
# If not running in OJB server mode (e.g. in desktop apps, or in a
servlet
# engine) it is save to use the InMemoryLockMapImpl. Using it will
result
# in a large performance gain.
# LockMapClass=org.apache.ojb.odmg.locking.PersistentLockMapImpl
LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
#
# The LockTimeout entry defines the maximum time in milliseconds
# that a lock may be hold. Defaults to 60000 = 1 minute
LockTimeout=60000
#
# The ImplicitLocking entry defines if implicit lock acquisition is
# to be used. If set to true OJB implicitely locks objects to ODMG
# transactions after performing OQL queries.
# If implicit locking is used locking objects is recursive, that is
# associated objects are also locked.
# If ImplicitLocking is set to false, no locks are obtained in OQL
# queries and there is also no recursive locking.
ImplicitLocking=true
#ImplicitLocking=false
#
# The LockAssociations entry defines the behaviour for the OJB
# implicit locking feature. If set to WRITE (default) acquiring a write-
# lock on a given object x implies write locks on all objects associated
# to x. If set to READ implicit read-locks are acquired.
# Acquiring a read-lock on x thus allways results in implicit read-locks
# on all associated objects.
#LockAssociations=READ
LockAssociations=WRITE
#
#
#----------------------------------------------------------------------------------------
# Logging
#----------------------------------------------------------------------------------------
#
# The LoggerClass entry tells OJB which concrete Logger
# implementation is to be used.
#
# Commons-logging
#LoggerClass=org.apache.ojb.broker.util.logging.CommonsLoggerImpl
# log4j based logging
#LoggerClass=org.apache.ojb.broker.util.logging.Log4jLoggerImpl
# OJB's own simple looging support
LoggerClass=org.apache.ojb.broker.util.logging.PoorMansLoggerImpl
LoggerConfigFile=log4j.properties
#
# The LogLevel entries tells OJB which LogLevels are active
# for the different loggers used within OJB
# Loglevels: DEBUG < INFO < WARN < ERROR < FATAL
# That is loglevel WARN won't log DEBUG and INFO messages,
# but will log WARN, ERROR, and FATAL messages
#
# The Default Logger
DEFAULT.LogLevel=WARN
# Loger for SqlGenerator, useful for debugging generation of SQL
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN
# Logger for JdbcAccess, useful for debugging JDBC related problems
org.apache.ojb.broker.accesslayer.JdbcAccess.LogLevel=DEBUG
# Logger for PersistenceBrokerImpl class
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.LogLevel=WARN
# Logger for PersistenceBrokerFactory class
org.apache.ojb.broker.PersistenceBrokerFactory.LogLevel=WARN
# Logger for PersistenceBrokerClient
org.apache.ojb.broker.server.PersistenceBrokerClient.LogLevel=WARN
# Logger for Serverside RequestProcessor
org.apache.ojb.broker.server.RequestProcessor.LogLevel=WARN
# Logger for BrokerPool
org.apache.ojb.broker.server.BrokerPool.LogLevel=WARN
# Logger for RepositoryXmlHandler, useful for debugging parsing of
repository.xml!
org.apache.ojb.broker.metadata.RepositoryXmlHandler.LogLevel=WARN
# Logger for RsIterator, useful for debugging problems with Object
materialization
org.apache.ojb.broker.accesslayer.RsIterator.LogLevel=WARN
# Logger for StatementsForClass, useful for debugging JDBC Connection
related problems
org.apache.ojb.broker.accesslayer.StatementsForClass.LogLevel=WARN
# Logger for the ODMG Implementation
ODMG.LogLevel=WARN
# Logger for the performance tests
performance.LogLevel=WARN
# Logger for the soda api
soda.LogLevel=WARN
# Logger for the factory service
ConfigurableFactory.LogLevel=WARN
#
#
#----------------------------------------------------------------------------------------
# OQL / SQL setting
#----------------------------------------------------------------------------------------
# The OqlCollectionClass entry defines the collection type returned
# from OQL queries. By default this value is set to DListImpl.
# This will be good for most situations as DList allows maximum
flexibility
# in a ODMG environment.
# Using DLists for large resultsets may be bad for application
performance.
# For these scenarios you can use ArrayLists or Vectors.
# Important note: the collections class to be used MUST implement the
# interface org.apache.ojb.broker.ManageableCollection.
#
OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl
#
OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
# OqlCollectionClass=org.apache.ojb.broker.util.ManageableVector
#
# The SqlInLimit entry limits the number of values in IN-sql statement,
# -1 for no limits. This hint is used in Criteria.
SqlInLimit=200
#
#
#----------------------------------------------------------------------------------------
# Meta data / mapping settings
#----------------------------------------------------------------------------------------
#
# The PersistentFieldClass property defines the implementation class
# for PersistentField attributes used in the OJB MetaData layer.
# By default a attribute based Version using Reflection is selected.
# using this Class persistent attributes don't need getters and setters
# and don't have to be declared public or protected.
#
#PersistentFieldClass=org.apache.ojb.broker.metadata.PersistentFieldDefaultImpl
#
# There is also a high-speed version of this access strategy avalaible.
# The PersistentFieldMaxPerformanceImpl does not cooperate with
# an AccessController, but accesses the fields directly.
#PersistentFieldClass=org.apache.ojb.broker.metadata.PersistentFieldMaxPerformanceImpl
#
# The PersistentFieldPropertyImpl uses JavaBeans comformant calls only
# to access persistent attributes. No Reflection is needed.
# But for each attribute xxx there must be public getXxx() and setXxx()
methods.
#
PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPropertyImpl
#
#
#----------------------------------------------------------------------------------------
# Component Intercepting for Profiling and Tracing
#----------------------------------------------------------------------------------------
#
# By enabling an InterceptorClass all OJB components will use
# this Interceptor. Interceptors allow advanced tracing and Profiling
# of all component method calls.
# This is currently an experimental feature useful only for OJB kernel
developers.
#
#InterceptorClass=org.apache.ojb.broker.util.interceptor.TracingInterceptor
#
#----------------------------------------------------------------------------------------
# Transaction Management and assocation
#----------------------------------------------------------------------------------------
# Use the LocalTxManager if you want the transaction to be associated by
a thread
OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
# Use the JTATxManager if you want the transaction to be associated via
the Transaction
# manager that is in your application server.
#OJBTxManagerClass=org.apache.ojb.odmg.JTATxManager
#
# The TransactionManager is acquired in different ways dependent on the
application server.
# The JTATransactionManagerClass property allows you to specify the
class that implements
# the proper behaviour for finding the transaction manager. Only use
when OJBTxManagerClass
# is set to a factory that uses the application server transaction
manager
# (org.apache.ojb.odmg.JTATxManager)
#
# JBoss Transaction Manager Factory
#
JTATransactionManagerClass=org.apache.ojb.otm.transaction.factory.JBossTransactionManagerFactory
# Weblogic Transaction Manager Factory
#JTATransactionManagerClass=org.apache.ojb.otm.transaction.factory.WeblogicTransactionManagerFactory
# WebSphere transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.otm.transaction.factory.WebSphereTransactionManagerFactory
#
#----------------------------------------------------------------------------------------
# Auto DB Creation / Transparent Datastore
#----------------------------------------------------------------------------------------
autobuild=false
#
#----------------------------------------------------------------------------------------
# End of OJB.properties file
#----------------------------------------------------------------------------------------
====================================================
Armin Waibel wrote:
>
> Hi again,
>
> hmm, looks fine for me.
> Could you post your OJB.properties file please.
>
> > > > > > the ConnectionFactoryClass to ConnectionFactoryNotPooledImpl
> > > > > > instead of
> > > > > > the ConnectionFactoryManagedImpl (to make sure connections get
>
> what I don't understand is that these implementation classes do
> not exist in 0.9.7?
>
> > We do not use a pooling ConnectionFactory, and already tried the
> > ConnectionFactoryNotPooledImpl as mentoined earlier (see below):
>
> ok, how do you lookup connections? Using DataSource from your appServer
> or using 'direct' connections from the DriverManager?
>
> regards,
> Armin
>
> ----- Original Message -----
> From: "J Pielage" <[EMAIL PROTECTED]>
> To: "OJB Users List" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 18, 2003 1:01 PM
> Subject: Re: Troubles with Websphere / OJB / Oracle application
>
> > Hi Armin,
> >
> >
> > The code which get's called in our stress test looks like this:
> >
> > public static Medewerker getMedewerkerByLogin(String login) {
> > Criteria crit = new Criteria();
> > crit.addEqualTo("login", login);
> > return (Medewerker) OJBHelper.getObjectByQuery(Medewerker.class,
> > crit);
> > }
> >
> > This uses the getObjectByQuery method in an class OJBHelper which
> looks
> > like this:
> >
> > /**
> > * Roept de getObjectByQuery methode van de PersistenceBroker aan
> > * @param ojbClass OJB class
> > * @param criteria Query criteria
> > * @return Object
> > */
> > public static Object getObjectByQuery(Class ojbClass, Criteria
> > criteria) {
> > PersistenceBroker broker = null;
> > Object retval = null;
> >
> > try {
> > Query q = QueryFactory.newQuery(ojbClass, criteria);
> >
> > // run query
> > broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> > retval = broker.getObjectByQuery(q);
> >
> > } finally {
> > if (broker != null) {
> > broker.close();
> > }
> > }
> >
> > return retval;
> > }
> >
> > We do not use a pooling ConnectionFactory, and already tried the
> > ConnectionFactoryNotPooledImpl as mentoined earlier (see below):
> >
> > > > > > We tried several settings in the OJB.properties file,
> > > > > > especially setting
> > > > > > the ConnectionFactoryClass to ConnectionFactoryNotPooledImpl
> > > > > > instead of
> > > > > > the ConnectionFactoryManagedImpl (to make sure connections get
> > > closed,
> > > > > > that is returned to the data source connection pool) but that
> > > didn't
> > > > > > help.
> >
> > Thanks, Jeroen
> >
> >
> >
> >
> > Armin Waibel wrote:
> > >
> > > Hi,
> > >
> > > could you post the code for the stress test or
> > > some pseudo code to see how you get broker
> > > instances, ...?
> > >
> > > > We use an Oracle (9.0.1) connection pooled datasource from OJB
> > >
> > > If using DataSource from the appServer don't use a pooling
> > > ConnectionFactory in OJB too. In current version OJB never
> > > pools connections obtained via DataSource, in 0.9.7 I
> > > think you should use ConnectionFactoryNotPooledImpl.
> > >
> > > Do you have tried to increase the max connections
> > > limit (e.g. double the number of connections the test pass
> > > with jdbc)?
> > >
> > > regards,
> > > Armin
> > >
> > > ----- Original Message -----
> > > From: "J Pielage" <[EMAIL PROTECTED]>
> > > To: "OJB Users List" <[EMAIL PROTECTED]>
> > > Sent: Wednesday, June 18, 2003 11:43 AM
> > > Subject: Re: Troubles with Websphere / OJB / Oracle application
> > >
> > > > Hi Thomas,
> > > >
> > > > Thanks for the quick response, really appreciate it!
> > > >
> > > > We are currently re-checking if all the brokers get closed, we
> > > normally
> > > > do that in finally blocks, well, everything seems to be allright
> so
> > > far.
> > > >
> > > > We singled out a single simple query functionality in our app for
> the
> > > > stress testing, and I already verified that any brokers that are
> used
> > > in
> > > > this case are properly closed. So that doesn't seem to be the
> > > problem...
> > > >
> > > > BTW, forgot to mention, we are using the odmg api for inserts,
> > > deletes,
> > > > and updates, but using the PersistenceBroker for running queries.
> (We
> > > > read-lock any objects that get returned by the brokers inside odmg
> > > > transactions.)
> > > >
> > > >
> > > > Jeroen
> > > >
> > > >
> > > >
> > > > Mahler Thomas wrote:
> > > > >
> > > > > Hi jeroen,
> > > > >
> > > > > are you sure you properly close all broker instances after
> usage?
> > > > > If you don't close broker instances after usage they are not
> made
> > > available
> > > > > to the pool and thus a shortage of available db connections is
> > > likely to
> > > > > happen!
> > > > >
> > > > > cheers,
> > > > > Thomas
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: J Pielage [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Wednesday, June 18, 2003 10:28 AM
> > > > > > To: OJB Users List
> > > > > > Subject: Troubles with Websphere / OJB / Oracle application
> > > > > >
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > We are stress testing an J2EE application on Websphere App
> > > > > > Server 4.0.3
> > > > > > and running into problems. We use OJB v 0.9.7 for the data
> layer,
> > > > > > instead of entity EJB's. The OJB functionality is called from
> > > > > > a layer of
> > > > > > stateless session EJB's.
> > > > > >
> > > > > > The problem is that, when running requests from different
> > > > > > clients at the
> > > > > > same time, numerous requests to the database time out, likely
> > > > > > because of
> > > > > > problems with getting a database connection.
> > > > > > We use an Oracle (9.0.1) connection pooled datasource from
> OJB.
> > > When
> > > > > > stress testing normal JDBC calls (not involving OJB) using the
> > > same
> > > > > > datasource, we experience no problems.
> > > > > >
> > > > > > So the problem is maybe in the configuration of the OJB layer.
> > > > > > We tried several settings in the OJB.properties file,
> > > > > > especially setting
> > > > > > the ConnectionFactoryClass to ConnectionFactoryNotPooledImpl
> > > > > > instead of
> > > > > > the ConnectionFactoryManagedImpl (to make sure connections get
> > > closed,
> > > > > > that is returned to the data source connection pool) but that
> > > didn't
> > > > > > help.
> > > > > >
> > > > > > We are currently running late with our project and running
> > > > > > out of ideas,
> > > > > > so if any of you could give us timely advice on this one, it
> would
> > > be
> > > > > > deeply appreciated. Especially, if you have experiences with a
> > > > > > production system with a similar architecture, it would be
> > > > > > very helpful
> > > > > > to know how you did configure OJB.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Jeroen Pielage
> > > > > > TNO
> > > > > > the Netherlands
> > > > > >
> > > > >
> > >
> > ---------------------------------------------------------------------
> > > > > > 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]
> > > >
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
