You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Bruno CROS <br...@gmail.com> on 2006/05/05 12:17:33 UTC
Only one PB from second database
Hi,
I have a strange behaviour about the second database i use. It seems that
using "broker = PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
always return the same broker/connection.
My connection pool is setup as it have to keep 2 idle connections
available, and it never occured. Still only one.
How can i use several connection in this case?
Note that this database is not not use to update datas. No transaction are
used on it.
Thanks.
Here's my connection setup.
<jdbc-connection-descriptor
jcd-alias="rushDb"
default-connection="false"
platform="MsSQLServer"
jdbc-level="2.0"
driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
protocol="JDBC"
subprotocol="microsoft:sqlserver"
dbalias="//xxx.x.x.x:1433"
username="xxxx"
password="xxxx"
batch-mode="true"
useAutoCommit="0"
ignoreAutoCommitExceptions="true"
>
and pool setup :
maxActive="5"
maxIdle="-1"
minIdle="2"
maxWait="5000"
whenExhaustedAction="2"
validationQuery="SELECT CURRENT_TIMESTAMP"
testOnBorrow="true"
testOnReturn="false"
testWhileIdle="true"
timeBetweenEvictionRunsMillis="60000"
numTestsPerEvictionRun="2"
minEvictableIdleTimeMillis="1800000"
removedAbandonned="false"
removeAbandonedTimeout="300"
logAbandoned="true">
Re: Only one PB from second database
Posted by Armin Waibel <ar...@apache.org>.
Bruno CROS wrote:
> Yep, i 'm affraid that _pool.size() is always > than -1 !! (the
> maxIdle), so
> "shouldDestroy" is true, and no pool is added.
>
> May be it's me . Someone can confirm this ?
>
Yep! The pool is always empty.
I would recommend first to try the connection-pool default settings
shipped with OJB (adapt maxActive is ok). These settings are well
tested. If this works for you start varying the default settings.
If you handle the "read-only" broker instances correctly (e.g. close it
immediately after use, ...) I don't have a clue why this freeze happens
- maybe a commons-pool issue.
By the way, I don't recommend to set logAbandoned="true" (when using
ConnectionFactoryDBCPImpl) particularly in production environment
because it's costly to trace connections. Each abandoned connection is
bug and should be fixed.
regards,
Armin
>
>
> private void addObjectToPool(Object obj, boolean decrementNumActive)
> throws Exception {
> boolean success = true;
> if(_testOnReturn && !(_factory.validateObject(obj))) {
> success = false;
> } else {
> try {
> _factory.passivateObject(obj);
> } catch(Exception e) {
> success = false;
> }
> }
>
> boolean shouldDestroy = !success;
>
> if (decrementNumActive) {
> _numActive--;
> }
> if((_maxIdle >= 0) && (_pool.size() >= _maxIdle)) {
> shouldDestroy = true;
> } else if(success) {
> _pool.addLast(new ObjectTimestampPair(obj));
> }
> notifyAll(); // _numActive has changed
>
> if(shouldDestroy) {
> try {
> _factory.destroyObject(obj);
> } catch(Exception e) {
> // ignored
> }
> }
> }
>
>
> On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
>>
>>
>>
>> Bruno CROS wrote:
>> > when MaxIdle is set to 0, it works well, and the 5 maxActive are
>> > sufficient.
>> > No freeze at all.
>>
>> it's a moot point whether only one connection or five connections are
>> used when maxIdle is 0. I think that maxIdle=0 will immediately close
>> returned connections.
>>
>>
>> >
>> > The whenExhaustedAction block is well what i want, no error. And it
>> works
>> > with maxIdle set to 0.
>> >
>> > I don't see why no connection remaining in the pool leads to a
>> > serialization. Dead lock is a good assumption, it looks like that, but
>> if
>> > code only reads, i don't known at all how to produce dead lock.
>>
>> A deadlock caused by the pool and and depended broker instances (one
>> broker wait for a result of another one or a broker leak), not a
>> database deadlock.
>>
>> > I'm
>> > going to
>> > look at common-pool settings, if maxIdle is common-pool setting.
>>
>> yep, maxIdle is a commons-pool setting. I would recommend to check the
>> source code.
>> http://jakarta.apache.org/commons/pool/cvs-usage.html
>> (currently the apache svn is down due a SVN-server problem last night,
>> so download the sources).
>>
>> regards,
>> Armin
>>
>> >
>> > regards
>> >
>> >
>> >
>> >
>> >
>> > On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
>> >>
>> >> Bruno CROS wrote:
>> >> > Hi Armin,
>> >> >
>> >> > autoCommit set to 1 does not avoid freeze. The fact is that database
>> is
>> >> > only
>> >> > used to be read, so rollbacks ( by disconnecting) will never be
>> long.
>> >> > autocommit is however set to 1 now. Thanks for the advice.
>> >> >
>> >> > I dont' known why it freezes when maxIdle set to -1 and why it does
>> not
>> >> > when
>> >> > maxIdle is set to 0. But if i well guess, 0 closes usable
>> connections,
>> >> > that's it ?! So it's not optimized.
>> >> >
>> >>
>> >> You enabled whenExhaustedAction="1" this mean that the pool blocks
>> till
>> >> a connection was returned. Max active connections is set to 5 this
>> isn't
>> >> much for a mulithreaded application. Maybe your application cause a
>> >> deadlock, five different broker instances exhaust the pool and another
>> >> broker instance try to lookup a connection but other broker instances
>> >> still not closed.
>> >> What happens when you set whenExhaustedAction="0"?
>> >>
>> >> I think if you set maxIdle=0 only one connection or none connections
>> >> will remain in the pool (maybe I'm wrong, I don't check commons-pool
>> >> sources) and all access is "serialized" by this.
>> >>
>> >> regards,
>> >> Armin
>> >>
>> >>
>> >> > Here's my well working conn setup
>> >> >
>> >> > Regards.
>> >> >
>> >> >
>> >> > <connection-pool
>> >> > maxActive="5"
>> >> > maxIdle="0"
>> >> > minIdle="2"
>> >> > maxWait="1000"
>> >> > whenExhaustedAction="1"
>> >> >
>> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
>> >> > testOnBorrow="true"
>> >> > testOnReturn="false"
>> >> > testWhileIdle="true"
>> >> > timeBetweenEvictionRunsMillis="60000"
>> >> > numTestsPerEvictionRun="2"
>> >> > minEvictableIdleTimeMillis="1800000"
>> >> > removedAbandonned="false"
>> >> > removeAbandonedTimeout="300"
>> >> > logAbandoned="true">
>> >> >
>> >> > <!-- Set fetchSize to 0 to use driver's default. -->
>> >> > <attribute attribute-name="fetchSize"
>> attribute-value="0"/>
>> >> >
>> >> > <!-- Attributes with name prefix "jdbc." are passed
>> directly
>> >> to
>> >> > the JDBC driver. -->
>> >> > <!-- Example setting (used by Oracle driver when
>> Statement
>> >> > batching is enabled) -->
>> >> > <attribute attribute-name="jdbc.defaultBatchValue"
>> >> > attribute-value="5"/>
>> >> >
>> >> > <!-- Attributes determining if ConnectionFactoryDBCPImpl
>> >> > should also pool PreparedStatement. This is
>> >> > programmatically disabled
>> >> > when using platform=Oracle9i since Oracle statement
>> >> caching
>> >> > will conflict
>> >> > with DBCP ObjectPool-based PreparepdStatement
>> caching
>> >> (ie
>> >> > setting true
>> >> > here has no effect for Oracle9i platform). -->
>> >> > <attribute attribute-name="dbcp.poolPreparedStatements"
>> >> > attribute-value="false"/>
>> >> > <attribute
>> attribute-name="dbcp.maxOpenPreparedStatements"
>> >> > attribute-value="10"/>
>> >> > <!-- Attribute determining if the Commons DBCP connection
>> >> > wrapper will allow
>> >> > access to the underlying concrete Connection
>> instance
>> >> from
>> >> > the JDBC-driver
>> >> > (normally this is not allowed, like in
>> J2EE-containers
>> >> > using wrappers). -->
>> >> > <attribute attribute-name="
>> >> > dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
>> >> > </connection-pool>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 5/6/06, Armin Waibel <ar...@apache.org> wrote:
>> >> >>
>> >> >> Hi Bruno,
>> >> >>
>> >> >> Bruno CROS wrote:
>> >> >> > Hi Armin,
>> >> >> >
>> >> >> > In fact, i looked at the DB connections in the DB console. It was
>> a
>> >> bad
>> >> >> > idea, because connection disappear !! I looked with netstat -a ,
>> and
>> >> i
>> >> >> saw
>> >> >> > several sockets/connections...
>> >> >> >
>> >> >> > Well, i was experiencing some freezes with these connections with
>> a
>> >> >> pool
>> >> >> > setup maxActive set to -1. I didn't find any documentation on
>> that
>> >> >> value.
>> >> >>
>> >> >> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
>> >> >> commons-pool to manage connections. There you can find details
>> about
>> >> the
>> >> >> settings
>> >> >> http://jakarta.apache.org/commons/pool/apidocs/index.html
>> >> >>
>> >> >> I would recommend to set maxActive connections at most to the
>> maximal
>> >> >> connections provided by your database server.
>> >> >>
>> >> >>
>> >> >> > What i known is that, when i put 0 (no limit), it seems there is
>> no
>> >> >> more
>> >> >> > freeze.
>> >> >> >
>> >> >>
>> >> >> I think there is a typo in documentation. For unlimited connection
>> >> pool
>> >> >> you have to set -1.
>> >> >>
>> >> >>
>> >>
>> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
>>
>> >>
>> >> >>
>> >> >> Will fix this till next release.
>> >> >>
>> >> >> In your jdbc-connection-descriptor (posted some time ago) you set
>> >> >> useAutoCommit="0". In this case you have to enable autoCommit
>> 'false'
>> >> in
>> >> >> your jdbc-driver configuration setup, else you will run into
>> rollback
>> >> >> hassle (if autoCommit is 'true' for connections).
>> >> >>
>> >> >> regards,
>> >> >> Armin
>> >> >>
>> >> >> > Can you ligth up me about that.
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >> > Regards.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
>> >> >> >>
>> >> >> >> Hi Bruno,
>> >> >> >>
>> >> >> >> Bruno CROS wrote:
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > I have a strange behaviour about the second database i
>> use. It
>> >> >> seems
>> >> >> >> that
>> >> >> >> > using "broker =
>> >> >> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> >> >> >> > always return the same broker/connection.
>> >> >> >> >
>> >> >> >> > My connection pool is setup as it have to keep 2 idle
>> connections
>> >> >> >> > available, and it never occured. Still only one.
>> >> >> >> >
>> >> >> >> > How can i use several connection in this case?
>> >> >> >> >
>> >> >> >> > Note that this database is not not use to update datas. No
>> >> >> transaction
>> >> >> >> are
>> >> >> >> > used on it.
>> >> >> >> >
>> >> >> >>
>> >> >> >> how do you test this behavior? Please setup a test and lookup
>> for
>> >> two
>> >> >> PB
>> >> >> >> instances at the same time:
>> >> >> >>
>> >> >> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker
>> >> ("rushDb");
>> >> >> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker
>> >> ("rushDb");
>> >> >> >>
>> >> >> >> Are A and B really the same broker instances? If you execute a
>> >> >> query on
>> >> >> >> both broker instances (don't close the broker after it) and then
>> >> >> lookup
>> >> >> >> the Connection from A and B - are the connections the same?
>> >> >> >>
>> >> >> >> regards,
>> >> >> >> Armin
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Thanks.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > Here's my connection setup.
>> >> >> >> >
>> >> >> >> > <jdbc-connection-descriptor
>> >> >> >> > jcd-alias="rushDb"
>> >> >> >> > default-connection="false"
>> >> >> >> > platform="MsSQLServer"
>> >> >> >> > jdbc-level="2.0"
>> >> >> >> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
>> >> >> >> > protocol="JDBC"
>> >> >> >> > subprotocol="microsoft:sqlserver"
>> >> >> >> > dbalias="//xxx.x.x.x:1433"
>> >> >> >> > username="xxxx"
>> >> >> >> > password="xxxx"
>> >> >> >> > batch-mode="true"
>> >> >> >> > useAutoCommit="0"
>> >> >> >> > ignoreAutoCommitExceptions="true"
>> >> >> >> > >
>> >> >> >> >
>> >> >> >> > and pool setup :
>> >> >> >> >
>> >> >> >> > maxActive="5"
>> >> >> >> > maxIdle="-1"
>> >> >> >> > minIdle="2"
>> >> >> >> > maxWait="5000"
>> >> >> >> > whenExhaustedAction="2"
>> >> >> >> >
>> >> >> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
>> >> >> >> > testOnBorrow="true"
>> >> >> >> > testOnReturn="false"
>> >> >> >> > testWhileIdle="true"
>> >> >> >> > timeBetweenEvictionRunsMillis="60000"
>> >> >> >> > numTestsPerEvictionRun="2"
>> >> >> >> > minEvictableIdleTimeMillis="1800000"
>> >> >> >> > removedAbandonned="false"
>> >> >> >> > removeAbandonedTimeout="300"
>> >> >> >> > logAbandoned="true">
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> 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
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Only one PB from second database
Posted by Bruno CROS <br...@gmail.com>.
Oops, it's me.
Sorry
On 5/11/06, Bruno CROS <br...@gmail.com> wrote:
>
> Yep, i 'm affraid that _pool.size() is always > than -1 !! (the maxIdle),
> so "shouldDestroy" is true, and no pool is added.
>
> May be it's me . Someone can confirm this ?
>
>
>
> private void addObjectToPool(Object obj, boolean decrementNumActive)
> throws Exception {
> boolean success = true;
> if(_testOnReturn && !(_factory.validateObject(obj))) {
> success = false;
> } else {
> try {
> _factory.passivateObject(obj);
> } catch(Exception e) {
> success = false;
> }
> }
>
> boolean shouldDestroy = !success;
>
> if (decrementNumActive) {
> _numActive--;
> }
> if((_maxIdle >= 0) && (_pool.size() >= _maxIdle)) {
> shouldDestroy = true;
> } else if(success) {
> _pool.addLast(new ObjectTimestampPair(obj));
> }
> notifyAll(); // _numActive has changed
>
> if(shouldDestroy) {
> try {
> _factory.destroyObject(obj);
> } catch(Exception e) {
> // ignored
> }
> }
> }
>
>
> On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
> >
> >
> >
> > Bruno CROS wrote:
> > > when MaxIdle is set to 0, it works well, and the 5 maxActive are
> > > sufficient.
> > > No freeze at all.
> >
> > it's a moot point whether only one connection or five connections are
> > used when maxIdle is 0. I think that maxIdle=0 will immediately close
> > returned connections.
> >
> >
> > >
> > > The whenExhaustedAction block is well what i want, no error. And it
> > works
> > > with maxIdle set to 0.
> > >
> > > I don't see why no connection remaining in the pool leads to a
> > > serialization. Dead lock is a good assumption, it looks like that, but
> > if
> > > code only reads, i don't known at all how to produce dead lock.
> >
> > A deadlock caused by the pool and and depended broker instances (one
> > broker wait for a result of another one or a broker leak), not a
> > database deadlock.
> >
> > > I'm
> > > going to
> > > look at common-pool settings, if maxIdle is common-pool setting.
> >
> > yep, maxIdle is a commons-pool setting. I would recommend to check the
> > source code.
> > http://jakarta.apache.org/commons/pool/cvs-usage.html
> > (currently the apache svn is down due a SVN-server problem last night,
> > so download the sources).
> >
> > regards,
> > Armin
> >
> > >
> > > regards
> > >
> > >
> > >
> > >
> > >
> > > On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
> > >>
> > >> Bruno CROS wrote:
> > >> > Hi Armin,
> > >> >
> > >> > autoCommit set to 1 does not avoid freeze. The fact is that
> > database is
> > >> > only
> > >> > used to be read, so rollbacks ( by disconnecting) will never be
> > long.
> > >> > autocommit is however set to 1 now. Thanks for the advice.
> > >> >
> > >> > I dont' known why it freezes when maxIdle set to -1 and why it does
> > not
> > >> > when
> > >> > maxIdle is set to 0. But if i well guess, 0 closes usable
> > connections,
> > >> > that's it ?! So it's not optimized.
> > >> >
> > >>
> > >> You enabled whenExhaustedAction="1" this mean that the pool blocks
> > till
> > >> a connection was returned. Max active connections is set to 5 this
> > isn't
> > >> much for a mulithreaded application. Maybe your application cause a
> > >> deadlock, five different broker instances exhaust the pool and
> > another
> > >> broker instance try to lookup a connection but other broker instances
> > >> still not closed.
> > >> What happens when you set whenExhaustedAction="0"?
> > >>
> > >> I think if you set maxIdle=0 only one connection or none connections
> > >> will remain in the pool (maybe I'm wrong, I don't check commons-pool
> > >> sources) and all access is "serialized" by this.
> > >>
> > >> regards,
> > >> Armin
> > >>
> > >>
> > >> > Here's my well working conn setup
> > >> >
> > >> > Regards.
> > >> >
> > >> >
> > >> > <connection-pool
> > >> > maxActive="5"
> > >> > maxIdle="0"
> > >> > minIdle="2"
> > >> > maxWait="1000"
> > >> > whenExhaustedAction="1"
> > >> >
> > >> > validationQuery="SELECT CURRENT_TIMESTAMP"
> > >> > testOnBorrow="true"
> > >> > testOnReturn="false"
> > >> > testWhileIdle="true"
> > >> > timeBetweenEvictionRunsMillis="60000"
> > >> > numTestsPerEvictionRun="2"
> > >> > minEvictableIdleTimeMillis="1800000"
> > >> > removedAbandonned="false"
> > >> > removeAbandonedTimeout="300"
> > >> > logAbandoned="true">
> > >> >
> > >> > <!-- Set fetchSize to 0 to use driver's default. -->
> > >> > <attribute attribute-name="fetchSize"
> > attribute-value="0"/>
> > >> >
> > >> > <!-- Attributes with name prefix "jdbc." are passed
> > directly
> > >> to
> > >> > the JDBC driver. -->
> > >> > <!-- Example setting (used by Oracle driver when
> > Statement
> > >> > batching is enabled) -->
> > >> > <attribute attribute-name=" jdbc.defaultBatchValue"
> > >> > attribute-value="5"/>
> > >> >
> > >> > <!-- Attributes determining if ConnectionFactoryDBCPImpl
> > >> > should also pool PreparedStatement. This is
> > >> > programmatically disabled
> > >> > when using platform=Oracle9i since Oracle statement
> > >> caching
> > >> > will conflict
> > >> > with DBCP ObjectPool-based PreparepdStatement
> > caching
> > >> (ie
> > >> > setting true
> > >> > here has no effect for Oracle9i platform). -->
> > >> > <attribute attribute-name="dbcp.poolPreparedStatements"
> > >> > attribute-value="false"/>
> > >> > <attribute attribute-name="
> > dbcp.maxOpenPreparedStatements"
> > >> > attribute-value="10"/>
> > >> > <!-- Attribute determining if the Commons DBCP
> > connection
> > >> > wrapper will allow
> > >> > access to the underlying concrete Connection
> > instance
> > >> from
> > >> > the JDBC-driver
> > >> > (normally this is not allowed, like in
> > J2EE-containers
> > >> > using wrappers). -->
> > >> > <attribute attribute-name="
> > >> > dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
> > >> > </connection-pool>
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 5/6/06, Armin Waibel <arminw@apache.org > wrote:
> > >> >>
> > >> >> Hi Bruno,
> > >> >>
> > >> >> Bruno CROS wrote:
> > >> >> > Hi Armin,
> > >> >> >
> > >> >> > In fact, i looked at the DB connections in the DB console. It
> > was a
> > >> bad
> > >> >> > idea, because connection disappear !! I looked with netstat -a ,
> > and
> > >> i
> > >> >> saw
> > >> >> > several sockets/connections...
> > >> >> >
> > >> >> > Well, i was experiencing some freezes with these connections
> > with a
> > >> >> pool
> > >> >> > setup maxActive set to -1. I didn't find any documentation on
> > that
> > >> >> value.
> > >> >>
> > >> >> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
> > >> >> commons-pool to manage connections. There you can find details
> > about
> > >> the
> > >> >> settings
> > >> >> http://jakarta.apache.org/commons/pool/apidocs/index.html
> > >> >>
> > >> >> I would recommend to set maxActive connections at most to the
> > maximal
> > >> >> connections provided by your database server.
> > >> >>
> > >> >>
> > >> >> > What i known is that, when i put 0 (no limit), it seems there is
> > no
> > >> >> more
> > >> >> > freeze.
> > >> >> >
> > >> >>
> > >> >> I think there is a typo in documentation. For unlimited connection
> > >> pool
> > >> >> you have to set -1.
> > >> >>
> > >> >>
> > >> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
> >
> > >>
> > >> >>
> > >> >> Will fix this till next release.
> > >> >>
> > >> >> In your jdbc-connection-descriptor (posted some time ago) you set
> > >> >> useAutoCommit="0". In this case you have to enable autoCommit
> > 'false'
> > >> in
> > >> >> your jdbc-driver configuration setup, else you will run into
> > rollback
> > >> >> hassle (if autoCommit is 'true' for connections).
> > >> >>
> > >> >> regards,
> > >> >> Armin
> > >> >>
> > >> >> > Can you ligth up me about that.
> > >> >> >
> > >> >> > Thanks.
> > >> >> >
> > >> >> > Regards.
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
> > >> >> >>
> > >> >> >> Hi Bruno,
> > >> >> >>
> > >> >> >> Bruno CROS wrote:
> > >> >> >> > Hi,
> > >> >> >> >
> > >> >> >> > I have a strange behaviour about the second database i use.
> > It
> > >> >> seems
> > >> >> >> that
> > >> >> >> > using "broker =
> > >> >> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> > >> >> >> > always return the same broker/connection.
> > >> >> >> >
> > >> >> >> > My connection pool is setup as it have to keep 2 idle
> > connections
> > >> >> >> > available, and it never occured. Still only one.
> > >> >> >> >
> > >> >> >> > How can i use several connection in this case?
> > >> >> >> >
> > >> >> >> > Note that this database is not not use to update datas. No
> > >> >> transaction
> > >> >> >> are
> > >> >> >> > used on it.
> > >> >> >> >
> > >> >> >>
> > >> >> >> how do you test this behavior? Please setup a test and lookup
> > for
> > >> two
> > >> >> PB
> > >> >> >> instances at the same time:
> > >> >> >>
> > >> >> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker
> > >> ("rushDb");
> > >> >> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker
> > >> ("rushDb");
> > >> >> >>
> > >> >> >> Are A and B really the same broker instances? If you execute a
> > >> >> query on
> > >> >> >> both broker instances (don't close the broker after it) and
> > then
> > >> >> lookup
> > >> >> >> the Connection from A and B - are the connections the same?
> > >> >> >>
> > >> >> >> regards,
> > >> >> >> Armin
> > >> >> >>
> > >> >> >> >
> > >> >> >> > Thanks.
> > >> >> >> >
> > >> >> >> >
> > >> >> >> > Here's my connection setup.
> > >> >> >> >
> > >> >> >> > <jdbc-connection-descriptor
> > >> >> >> > jcd-alias="rushDb"
> > >> >> >> > default-connection="false"
> > >> >> >> > platform="MsSQLServer"
> > >> >> >> > jdbc-level="2.0"
> > >> >> >> > driver=" com.microsoft.jdbc.sqlserver.SQLServerDriver"
> > >> >> >> > protocol="JDBC"
> > >> >> >> > subprotocol="microsoft:sqlserver"
> > >> >> >> > dbalias="//xxx.x.x.x:1433"
> > >> >> >> > username="xxxx"
> > >> >> >> > password="xxxx"
> > >> >> >> > batch-mode="true"
> > >> >> >> > useAutoCommit="0"
> > >> >> >> > ignoreAutoCommitExceptions="true"
> > >> >> >> > >
> > >> >> >> >
> > >> >> >> > and pool setup :
> > >> >> >> >
> > >> >> >> > maxActive="5"
> > >> >> >> > maxIdle="-1"
> > >> >> >> > minIdle="2"
> > >> >> >> > maxWait="5000"
> > >> >> >> > whenExhaustedAction="2"
> > >> >> >> >
> > >> >> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
> > >> >> >> > testOnBorrow="true"
> > >> >> >> > testOnReturn="false"
> > >> >> >> > testWhileIdle="true"
> > >> >> >> > timeBetweenEvictionRunsMillis="60000"
> > >> >> >> > numTestsPerEvictionRun="2"
> > >> >> >> > minEvictableIdleTimeMillis="1800000"
> > >> >> >> > removedAbandonned="false"
> > >> >> >> > removeAbandonedTimeout="300"
> > >> >> >> > logAbandoned="true">
> > >> >> >> >
> > >> >> >>
> > >> >> >>
> > >> ---------------------------------------------------------------------
> > >> >> >> 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
> > >> >>
> > >> >>
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> >
> >
>
Re: Only one PB from second database
Posted by Bruno CROS <br...@gmail.com>.
Yep, i 'm affraid that _pool.size() is always > than -1 !! (the maxIdle), so
"shouldDestroy" is true, and no pool is added.
May be it's me . Someone can confirm this ?
private void addObjectToPool(Object obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(_testOnReturn && !(_factory.validateObject(obj))) {
success = false;
} else {
try {
_factory.passivateObject(obj);
} catch(Exception e) {
success = false;
}
}
boolean shouldDestroy = !success;
if (decrementNumActive) {
_numActive--;
}
if((_maxIdle >= 0) && (_pool.size() >= _maxIdle)) {
shouldDestroy = true;
} else if(success) {
_pool.addLast(new ObjectTimestampPair(obj));
}
notifyAll(); // _numActive has changed
if(shouldDestroy) {
try {
_factory.destroyObject(obj);
} catch(Exception e) {
// ignored
}
}
}
On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
>
>
>
> Bruno CROS wrote:
> > when MaxIdle is set to 0, it works well, and the 5 maxActive are
> > sufficient.
> > No freeze at all.
>
> it's a moot point whether only one connection or five connections are
> used when maxIdle is 0. I think that maxIdle=0 will immediately close
> returned connections.
>
>
> >
> > The whenExhaustedAction block is well what i want, no error. And it
> works
> > with maxIdle set to 0.
> >
> > I don't see why no connection remaining in the pool leads to a
> > serialization. Dead lock is a good assumption, it looks like that, but
> if
> > code only reads, i don't known at all how to produce dead lock.
>
> A deadlock caused by the pool and and depended broker instances (one
> broker wait for a result of another one or a broker leak), not a
> database deadlock.
>
> > I'm
> > going to
> > look at common-pool settings, if maxIdle is common-pool setting.
>
> yep, maxIdle is a commons-pool setting. I would recommend to check the
> source code.
> http://jakarta.apache.org/commons/pool/cvs-usage.html
> (currently the apache svn is down due a SVN-server problem last night,
> so download the sources).
>
> regards,
> Armin
>
> >
> > regards
> >
> >
> >
> >
> >
> > On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
> >>
> >> Bruno CROS wrote:
> >> > Hi Armin,
> >> >
> >> > autoCommit set to 1 does not avoid freeze. The fact is that database
> is
> >> > only
> >> > used to be read, so rollbacks ( by disconnecting) will never be long.
> >> > autocommit is however set to 1 now. Thanks for the advice.
> >> >
> >> > I dont' known why it freezes when maxIdle set to -1 and why it does
> not
> >> > when
> >> > maxIdle is set to 0. But if i well guess, 0 closes usable
> connections,
> >> > that's it ?! So it's not optimized.
> >> >
> >>
> >> You enabled whenExhaustedAction="1" this mean that the pool blocks till
> >> a connection was returned. Max active connections is set to 5 this
> isn't
> >> much for a mulithreaded application. Maybe your application cause a
> >> deadlock, five different broker instances exhaust the pool and another
> >> broker instance try to lookup a connection but other broker instances
> >> still not closed.
> >> What happens when you set whenExhaustedAction="0"?
> >>
> >> I think if you set maxIdle=0 only one connection or none connections
> >> will remain in the pool (maybe I'm wrong, I don't check commons-pool
> >> sources) and all access is "serialized" by this.
> >>
> >> regards,
> >> Armin
> >>
> >>
> >> > Here's my well working conn setup
> >> >
> >> > Regards.
> >> >
> >> >
> >> > <connection-pool
> >> > maxActive="5"
> >> > maxIdle="0"
> >> > minIdle="2"
> >> > maxWait="1000"
> >> > whenExhaustedAction="1"
> >> >
> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
> >> > testOnBorrow="true"
> >> > testOnReturn="false"
> >> > testWhileIdle="true"
> >> > timeBetweenEvictionRunsMillis="60000"
> >> > numTestsPerEvictionRun="2"
> >> > minEvictableIdleTimeMillis="1800000"
> >> > removedAbandonned="false"
> >> > removeAbandonedTimeout="300"
> >> > logAbandoned="true">
> >> >
> >> > <!-- Set fetchSize to 0 to use driver's default. -->
> >> > <attribute attribute-name="fetchSize"
> attribute-value="0"/>
> >> >
> >> > <!-- Attributes with name prefix "jdbc." are passed
> directly
> >> to
> >> > the JDBC driver. -->
> >> > <!-- Example setting (used by Oracle driver when Statement
> >> > batching is enabled) -->
> >> > <attribute attribute-name="jdbc.defaultBatchValue"
> >> > attribute-value="5"/>
> >> >
> >> > <!-- Attributes determining if ConnectionFactoryDBCPImpl
> >> > should also pool PreparedStatement. This is
> >> > programmatically disabled
> >> > when using platform=Oracle9i since Oracle statement
> >> caching
> >> > will conflict
> >> > with DBCP ObjectPool-based PreparepdStatement caching
> >> (ie
> >> > setting true
> >> > here has no effect for Oracle9i platform). -->
> >> > <attribute attribute-name="dbcp.poolPreparedStatements"
> >> > attribute-value="false"/>
> >> > <attribute attribute-name="dbcp.maxOpenPreparedStatements"
> >> > attribute-value="10"/>
> >> > <!-- Attribute determining if the Commons DBCP connection
> >> > wrapper will allow
> >> > access to the underlying concrete Connection instance
> >> from
> >> > the JDBC-driver
> >> > (normally this is not allowed, like in
> J2EE-containers
> >> > using wrappers). -->
> >> > <attribute attribute-name="
> >> > dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
> >> > </connection-pool>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On 5/6/06, Armin Waibel <ar...@apache.org> wrote:
> >> >>
> >> >> Hi Bruno,
> >> >>
> >> >> Bruno CROS wrote:
> >> >> > Hi Armin,
> >> >> >
> >> >> > In fact, i looked at the DB connections in the DB console. It was
> a
> >> bad
> >> >> > idea, because connection disappear !! I looked with netstat -a ,
> and
> >> i
> >> >> saw
> >> >> > several sockets/connections...
> >> >> >
> >> >> > Well, i was experiencing some freezes with these connections with
> a
> >> >> pool
> >> >> > setup maxActive set to -1. I didn't find any documentation on that
> >> >> value.
> >> >>
> >> >> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
> >> >> commons-pool to manage connections. There you can find details about
> >> the
> >> >> settings
> >> >> http://jakarta.apache.org/commons/pool/apidocs/index.html
> >> >>
> >> >> I would recommend to set maxActive connections at most to the
> maximal
> >> >> connections provided by your database server.
> >> >>
> >> >>
> >> >> > What i known is that, when i put 0 (no limit), it seems there is
> no
> >> >> more
> >> >> > freeze.
> >> >> >
> >> >>
> >> >> I think there is a typo in documentation. For unlimited connection
> >> pool
> >> >> you have to set -1.
> >> >>
> >> >>
> >>
> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
> >>
> >> >>
> >> >> Will fix this till next release.
> >> >>
> >> >> In your jdbc-connection-descriptor (posted some time ago) you set
> >> >> useAutoCommit="0". In this case you have to enable autoCommit
> 'false'
> >> in
> >> >> your jdbc-driver configuration setup, else you will run into
> rollback
> >> >> hassle (if autoCommit is 'true' for connections).
> >> >>
> >> >> regards,
> >> >> Armin
> >> >>
> >> >> > Can you ligth up me about that.
> >> >> >
> >> >> > Thanks.
> >> >> >
> >> >> > Regards.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
> >> >> >>
> >> >> >> Hi Bruno,
> >> >> >>
> >> >> >> Bruno CROS wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I have a strange behaviour about the second database i use. It
> >> >> seems
> >> >> >> that
> >> >> >> > using "broker =
> >> >> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> >> >> >> > always return the same broker/connection.
> >> >> >> >
> >> >> >> > My connection pool is setup as it have to keep 2 idle
> connections
> >> >> >> > available, and it never occured. Still only one.
> >> >> >> >
> >> >> >> > How can i use several connection in this case?
> >> >> >> >
> >> >> >> > Note that this database is not not use to update datas. No
> >> >> transaction
> >> >> >> are
> >> >> >> > used on it.
> >> >> >> >
> >> >> >>
> >> >> >> how do you test this behavior? Please setup a test and lookup for
> >> two
> >> >> PB
> >> >> >> instances at the same time:
> >> >> >>
> >> >> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker
> >> ("rushDb");
> >> >> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker
> >> ("rushDb");
> >> >> >>
> >> >> >> Are A and B really the same broker instances? If you execute a
> >> >> query on
> >> >> >> both broker instances (don't close the broker after it) and then
> >> >> lookup
> >> >> >> the Connection from A and B - are the connections the same?
> >> >> >>
> >> >> >> regards,
> >> >> >> Armin
> >> >> >>
> >> >> >> >
> >> >> >> > Thanks.
> >> >> >> >
> >> >> >> >
> >> >> >> > Here's my connection setup.
> >> >> >> >
> >> >> >> > <jdbc-connection-descriptor
> >> >> >> > jcd-alias="rushDb"
> >> >> >> > default-connection="false"
> >> >> >> > platform="MsSQLServer"
> >> >> >> > jdbc-level="2.0"
> >> >> >> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
> >> >> >> > protocol="JDBC"
> >> >> >> > subprotocol="microsoft:sqlserver"
> >> >> >> > dbalias="//xxx.x.x.x:1433"
> >> >> >> > username="xxxx"
> >> >> >> > password="xxxx"
> >> >> >> > batch-mode="true"
> >> >> >> > useAutoCommit="0"
> >> >> >> > ignoreAutoCommitExceptions="true"
> >> >> >> > >
> >> >> >> >
> >> >> >> > and pool setup :
> >> >> >> >
> >> >> >> > maxActive="5"
> >> >> >> > maxIdle="-1"
> >> >> >> > minIdle="2"
> >> >> >> > maxWait="5000"
> >> >> >> > whenExhaustedAction="2"
> >> >> >> >
> >> >> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
> >> >> >> > testOnBorrow="true"
> >> >> >> > testOnReturn="false"
> >> >> >> > testWhileIdle="true"
> >> >> >> > timeBetweenEvictionRunsMillis="60000"
> >> >> >> > numTestsPerEvictionRun="2"
> >> >> >> > minEvictableIdleTimeMillis="1800000"
> >> >> >> > removedAbandonned="false"
> >> >> >> > removeAbandonedTimeout="300"
> >> >> >> > logAbandoned="true">
> >> >> >> >
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> 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
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: Only one PB from second database
Posted by Armin Waibel <ar...@apache.org>.
Bruno CROS wrote:
> when MaxIdle is set to 0, it works well, and the 5 maxActive are
> sufficient.
> No freeze at all.
it's a moot point whether only one connection or five connections are
used when maxIdle is 0. I think that maxIdle=0 will immediately close
returned connections.
>
> The whenExhaustedAction block is well what i want, no error. And it works
> with maxIdle set to 0.
>
> I don't see why no connection remaining in the pool leads to a
> serialization. Dead lock is a good assumption, it looks like that, but if
> code only reads, i don't known at all how to produce dead lock.
A deadlock caused by the pool and and depended broker instances (one
broker wait for a result of another one or a broker leak), not a
database deadlock.
> I'm
> going to
> look at common-pool settings, if maxIdle is common-pool setting.
yep, maxIdle is a commons-pool setting. I would recommend to check the
source code.
http://jakarta.apache.org/commons/pool/cvs-usage.html
(currently the apache svn is down due a SVN-server problem last night,
so download the sources).
regards,
Armin
>
> regards
>
>
>
>
>
> On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
>>
>> Bruno CROS wrote:
>> > Hi Armin,
>> >
>> > autoCommit set to 1 does not avoid freeze. The fact is that database is
>> > only
>> > used to be read, so rollbacks ( by disconnecting) will never be long.
>> > autocommit is however set to 1 now. Thanks for the advice.
>> >
>> > I dont' known why it freezes when maxIdle set to -1 and why it does not
>> > when
>> > maxIdle is set to 0. But if i well guess, 0 closes usable connections,
>> > that's it ?! So it's not optimized.
>> >
>>
>> You enabled whenExhaustedAction="1" this mean that the pool blocks till
>> a connection was returned. Max active connections is set to 5 this isn't
>> much for a mulithreaded application. Maybe your application cause a
>> deadlock, five different broker instances exhaust the pool and another
>> broker instance try to lookup a connection but other broker instances
>> still not closed.
>> What happens when you set whenExhaustedAction="0"?
>>
>> I think if you set maxIdle=0 only one connection or none connections
>> will remain in the pool (maybe I'm wrong, I don't check commons-pool
>> sources) and all access is "serialized" by this.
>>
>> regards,
>> Armin
>>
>>
>> > Here's my well working conn setup
>> >
>> > Regards.
>> >
>> >
>> > <connection-pool
>> > maxActive="5"
>> > maxIdle="0"
>> > minIdle="2"
>> > maxWait="1000"
>> > whenExhaustedAction="1"
>> >
>> > validationQuery="SELECT CURRENT_TIMESTAMP"
>> > testOnBorrow="true"
>> > testOnReturn="false"
>> > testWhileIdle="true"
>> > timeBetweenEvictionRunsMillis="60000"
>> > numTestsPerEvictionRun="2"
>> > minEvictableIdleTimeMillis="1800000"
>> > removedAbandonned="false"
>> > removeAbandonedTimeout="300"
>> > logAbandoned="true">
>> >
>> > <!-- Set fetchSize to 0 to use driver's default. -->
>> > <attribute attribute-name="fetchSize" attribute-value="0"/>
>> >
>> > <!-- Attributes with name prefix "jdbc." are passed directly
>> to
>> > the JDBC driver. -->
>> > <!-- Example setting (used by Oracle driver when Statement
>> > batching is enabled) -->
>> > <attribute attribute-name="jdbc.defaultBatchValue"
>> > attribute-value="5"/>
>> >
>> > <!-- Attributes determining if ConnectionFactoryDBCPImpl
>> > should also pool PreparedStatement. This is
>> > programmatically disabled
>> > when using platform=Oracle9i since Oracle statement
>> caching
>> > will conflict
>> > with DBCP ObjectPool-based PreparepdStatement caching
>> (ie
>> > setting true
>> > here has no effect for Oracle9i platform). -->
>> > <attribute attribute-name="dbcp.poolPreparedStatements"
>> > attribute-value="false"/>
>> > <attribute attribute-name="dbcp.maxOpenPreparedStatements"
>> > attribute-value="10"/>
>> > <!-- Attribute determining if the Commons DBCP connection
>> > wrapper will allow
>> > access to the underlying concrete Connection instance
>> from
>> > the JDBC-driver
>> > (normally this is not allowed, like in J2EE-containers
>> > using wrappers). -->
>> > <attribute attribute-name="
>> > dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
>> > </connection-pool>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 5/6/06, Armin Waibel <ar...@apache.org> wrote:
>> >>
>> >> Hi Bruno,
>> >>
>> >> Bruno CROS wrote:
>> >> > Hi Armin,
>> >> >
>> >> > In fact, i looked at the DB connections in the DB console. It was a
>> bad
>> >> > idea, because connection disappear !! I looked with netstat -a , and
>> i
>> >> saw
>> >> > several sockets/connections...
>> >> >
>> >> > Well, i was experiencing some freezes with these connections with a
>> >> pool
>> >> > setup maxActive set to -1. I didn't find any documentation on that
>> >> value.
>> >>
>> >> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
>> >> commons-pool to manage connections. There you can find details about
>> the
>> >> settings
>> >> http://jakarta.apache.org/commons/pool/apidocs/index.html
>> >>
>> >> I would recommend to set maxActive connections at most to the maximal
>> >> connections provided by your database server.
>> >>
>> >>
>> >> > What i known is that, when i put 0 (no limit), it seems there is no
>> >> more
>> >> > freeze.
>> >> >
>> >>
>> >> I think there is a typo in documentation. For unlimited connection
>> pool
>> >> you have to set -1.
>> >>
>> >>
>> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
>>
>> >>
>> >> Will fix this till next release.
>> >>
>> >> In your jdbc-connection-descriptor (posted some time ago) you set
>> >> useAutoCommit="0". In this case you have to enable autoCommit 'false'
>> in
>> >> your jdbc-driver configuration setup, else you will run into rollback
>> >> hassle (if autoCommit is 'true' for connections).
>> >>
>> >> regards,
>> >> Armin
>> >>
>> >> > Can you ligth up me about that.
>> >> >
>> >> > Thanks.
>> >> >
>> >> > Regards.
>> >> >
>> >> >
>> >> >
>> >> > On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
>> >> >>
>> >> >> Hi Bruno,
>> >> >>
>> >> >> Bruno CROS wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I have a strange behaviour about the second database i use. It
>> >> seems
>> >> >> that
>> >> >> > using "broker =
>> >> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> >> >> > always return the same broker/connection.
>> >> >> >
>> >> >> > My connection pool is setup as it have to keep 2 idle connections
>> >> >> > available, and it never occured. Still only one.
>> >> >> >
>> >> >> > How can i use several connection in this case?
>> >> >> >
>> >> >> > Note that this database is not not use to update datas. No
>> >> transaction
>> >> >> are
>> >> >> > used on it.
>> >> >> >
>> >> >>
>> >> >> how do you test this behavior? Please setup a test and lookup for
>> two
>> >> PB
>> >> >> instances at the same time:
>> >> >>
>> >> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker
>> ("rushDb");
>> >> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker
>> ("rushDb");
>> >> >>
>> >> >> Are A and B really the same broker instances? If you execute a
>> >> query on
>> >> >> both broker instances (don't close the broker after it) and then
>> >> lookup
>> >> >> the Connection from A and B - are the connections the same?
>> >> >>
>> >> >> regards,
>> >> >> Armin
>> >> >>
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >> >
>> >> >> > Here's my connection setup.
>> >> >> >
>> >> >> > <jdbc-connection-descriptor
>> >> >> > jcd-alias="rushDb"
>> >> >> > default-connection="false"
>> >> >> > platform="MsSQLServer"
>> >> >> > jdbc-level="2.0"
>> >> >> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
>> >> >> > protocol="JDBC"
>> >> >> > subprotocol="microsoft:sqlserver"
>> >> >> > dbalias="//xxx.x.x.x:1433"
>> >> >> > username="xxxx"
>> >> >> > password="xxxx"
>> >> >> > batch-mode="true"
>> >> >> > useAutoCommit="0"
>> >> >> > ignoreAutoCommitExceptions="true"
>> >> >> > >
>> >> >> >
>> >> >> > and pool setup :
>> >> >> >
>> >> >> > maxActive="5"
>> >> >> > maxIdle="-1"
>> >> >> > minIdle="2"
>> >> >> > maxWait="5000"
>> >> >> > whenExhaustedAction="2"
>> >> >> >
>> >> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
>> >> >> > testOnBorrow="true"
>> >> >> > testOnReturn="false"
>> >> >> > testWhileIdle="true"
>> >> >> > timeBetweenEvictionRunsMillis="60000"
>> >> >> > numTestsPerEvictionRun="2"
>> >> >> > minEvictableIdleTimeMillis="1800000"
>> >> >> > removedAbandonned="false"
>> >> >> > removeAbandonedTimeout="300"
>> >> >> > logAbandoned="true">
>> >> >> >
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> 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
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> 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
Re: Only one PB from second database
Posted by Bruno CROS <br...@gmail.com>.
No idea. All is ok on paper!
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
On 5/11/06, Bruno CROS <br...@gmail.com> wrote:
>
> when MaxIdle is set to 0, it works well, and the 5 maxActive are
> sufficient. No freeze at all.
>
> The whenExhaustedAction block is well what i want, no error. And it works
> with maxIdle set to 0.
>
> I don't see why no connection remaining in the pool leads to a
> serialization. Dead lock is a good assumption, it looks like that, but if
> code only reads, i don't known at all how to produce dead lock. I'm going to
> look at common-pool settings, if maxIdle is common-pool setting.
>
> regards
>
>
>
>
>
> On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
> >
> > Bruno CROS wrote:
> > > Hi Armin,
> > >
> > > autoCommit set to 1 does not avoid freeze. The fact is that database
> > is
> > > only
> > > used to be read, so rollbacks ( by disconnecting) will never be long.
> > > autocommit is however set to 1 now. Thanks for the advice.
> > >
> > > I dont' known why it freezes when maxIdle set to -1 and why it does
> > not
> > > when
> > > maxIdle is set to 0. But if i well guess, 0 closes usable connections,
> > > that's it ?! So it's not optimized.
> > >
> >
> > You enabled whenExhaustedAction="1" this mean that the pool blocks till
> > a connection was returned. Max active connections is set to 5 this isn't
> > much for a mulithreaded application. Maybe your application cause a
> > deadlock, five different broker instances exhaust the pool and another
> > broker instance try to lookup a connection but other broker instances
> > still not closed.
> > What happens when you set whenExhaustedAction="0"?
> >
> > I think if you set maxIdle=0 only one connection or none connections
> > will remain in the pool (maybe I'm wrong, I don't check commons-pool
> > sources) and all access is "serialized" by this.
> >
> > regards,
> > Armin
> >
> >
> > > Here's my well working conn setup
> > >
> > > Regards.
> > >
> > >
> > > <connection-pool
> > > maxActive="5"
> > > maxIdle="0"
> > > minIdle="2"
> > > maxWait="1000"
> > > whenExhaustedAction="1"
> > >
> > > validationQuery="SELECT CURRENT_TIMESTAMP"
> > > testOnBorrow="true"
> > > testOnReturn="false"
> > > testWhileIdle="true"
> > > timeBetweenEvictionRunsMillis="60000"
> > > numTestsPerEvictionRun="2"
> > > minEvictableIdleTimeMillis="1800000"
> > > removedAbandonned="false"
> > > removeAbandonedTimeout="300"
> > > logAbandoned="true">
> > >
> > > <!-- Set fetchSize to 0 to use driver's default. -->
> > > <attribute attribute-name="fetchSize" attribute-value="0"/>
> > >
> > > <!-- Attributes with name prefix "jdbc." are passed
> > directly to
> > > the JDBC driver. -->
> > > <!-- Example setting (used by Oracle driver when Statement
> > > batching is enabled) -->
> > > <attribute attribute-name="jdbc.defaultBatchValue"
> > > attribute-value="5"/>
> > >
> > > <!-- Attributes determining if ConnectionFactoryDBCPImpl
> > > should also pool PreparedStatement. This is
> > > programmatically disabled
> > > when using platform=Oracle9i since Oracle statement
> > caching
> > > will conflict
> > > with DBCP ObjectPool-based PreparepdStatement caching
> > (ie
> > > setting true
> > > here has no effect for Oracle9i platform). -->
> > > <attribute attribute-name=" dbcp.poolPreparedStatements"
> > > attribute-value="false"/>
> > > <attribute attribute-name="dbcp.maxOpenPreparedStatements"
> > > attribute-value="10"/>
> > > <!-- Attribute determining if the Commons DBCP connection
> > > wrapper will allow
> > > access to the underlying concrete Connection instance
> > from
> > > the JDBC-driver
> > > (normally this is not allowed, like in J2EE-containers
> > > using wrappers). -->
> > > <attribute attribute-name="
> > > dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
> > > </connection-pool>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 5/6/06, Armin Waibel <ar...@apache.org> wrote:
> > >>
> > >> Hi Bruno,
> > >>
> > >> Bruno CROS wrote:
> > >> > Hi Armin,
> > >> >
> > >> > In fact, i looked at the DB connections in the DB console. It was a
> > bad
> > >> > idea, because connection disappear !! I looked with netstat -a ,
> > and i
> > >> saw
> > >> > several sockets/connections...
> > >> >
> > >> > Well, i was experiencing some freezes with these connections with a
> > >> pool
> > >> > setup maxActive set to -1. I didn't find any documentation on that
> > >> value.
> > >>
> > >> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
> > >> commons-pool to manage connections. There you can find details about
> > the
> > >> settings
> > >> http://jakarta.apache.org/commons/pool/apidocs/index.html
> > >>
> > >> I would recommend to set maxActive connections at most to the maximal
> > >> connections provided by your database server.
> > >>
> > >>
> > >> > What i known is that, when i put 0 (no limit), it seems there is no
> > >> more
> > >> > freeze.
> > >> >
> > >>
> > >> I think there is a typo in documentation. For unlimited connection
> > pool
> > >> you have to set -1.
> > >>
> > >> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
> >
> > >>
> > >> Will fix this till next release.
> > >>
> > >> In your jdbc-connection-descriptor (posted some time ago) you set
> > >> useAutoCommit="0". In this case you have to enable autoCommit 'false'
> > in
> > >> your jdbc-driver configuration setup, else you will run into rollback
> > >> hassle (if autoCommit is 'true' for connections).
> > >>
> > >> regards,
> > >> Armin
> > >>
> > >> > Can you ligth up me about that.
> > >> >
> > >> > Thanks.
> > >> >
> > >> > Regards.
> > >> >
> > >> >
> > >> >
> > >> > On 5/5/06, Armin Waibel <arminw@apache.org > wrote:
> > >> >>
> > >> >> Hi Bruno,
> > >> >>
> > >> >> Bruno CROS wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > I have a strange behaviour about the second database i use. It
> > >> seems
> > >> >> that
> > >> >> > using "broker =
> > >> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> > >> >> > always return the same broker/connection.
> > >> >> >
> > >> >> > My connection pool is setup as it have to keep 2 idle
> > connections
> > >> >> > available, and it never occured. Still only one.
> > >> >> >
> > >> >> > How can i use several connection in this case?
> > >> >> >
> > >> >> > Note that this database is not not use to update datas. No
> > >> transaction
> > >> >> are
> > >> >> > used on it.
> > >> >> >
> > >> >>
> > >> >> how do you test this behavior? Please setup a test and lookup for
> > two
> > >> PB
> > >> >> instances at the same time:
> > >> >>
> > >> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker
> > ("rushDb");
> > >> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
> >
> > >> >>
> > >> >> Are A and B really the same broker instances? If you execute a
> > >> query on
> > >> >> both broker instances (don't close the broker after it) and then
> > >> lookup
> > >> >> the Connection from A and B - are the connections the same?
> > >> >>
> > >> >> regards,
> > >> >> Armin
> > >> >>
> > >> >> >
> > >> >> > Thanks.
> > >> >> >
> > >> >> >
> > >> >> > Here's my connection setup.
> > >> >> >
> > >> >> > <jdbc-connection-descriptor
> > >> >> > jcd-alias="rushDb"
> > >> >> > default-connection="false"
> > >> >> > platform="MsSQLServer"
> > >> >> > jdbc-level="2.0"
> > >> >> > driver=" com.microsoft.jdbc.sqlserver.SQLServerDriver"
> > >> >> > protocol="JDBC"
> > >> >> > subprotocol="microsoft:sqlserver"
> > >> >> > dbalias="//xxx.x.x.x:1433"
> > >> >> > username="xxxx"
> > >> >> > password="xxxx"
> > >> >> > batch-mode="true"
> > >> >> > useAutoCommit="0"
> > >> >> > ignoreAutoCommitExceptions="true"
> > >> >> > >
> > >> >> >
> > >> >> > and pool setup :
> > >> >> >
> > >> >> > maxActive="5"
> > >> >> > maxIdle="-1"
> > >> >> > minIdle="2"
> > >> >> > maxWait="5000"
> > >> >> > whenExhaustedAction="2"
> > >> >> >
> > >> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
> > >> >> > testOnBorrow="true"
> > >> >> > testOnReturn="false"
> > >> >> > testWhileIdle="true"
> > >> >> > timeBetweenEvictionRunsMillis="60000"
> > >> >> > numTestsPerEvictionRun="2"
> > >> >> > minEvictableIdleTimeMillis="1800000"
> > >> >> > removedAbandonned="false"
> > >> >> > removeAbandonedTimeout="300"
> > >> >> > logAbandoned="true">
> > >> >> >
> > >> >>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> 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
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> >
>
Re: Only one PB from second database
Posted by Bruno CROS <br...@gmail.com>.
when MaxIdle is set to 0, it works well, and the 5 maxActive are sufficient.
No freeze at all.
The whenExhaustedAction block is well what i want, no error. And it works
with maxIdle set to 0.
I don't see why no connection remaining in the pool leads to a
serialization. Dead lock is a good assumption, it looks like that, but if
code only reads, i don't known at all how to produce dead lock. I'm going to
look at common-pool settings, if maxIdle is common-pool setting.
regards
On 5/11/06, Armin Waibel <ar...@apache.org> wrote:
>
> Bruno CROS wrote:
> > Hi Armin,
> >
> > autoCommit set to 1 does not avoid freeze. The fact is that database is
> > only
> > used to be read, so rollbacks ( by disconnecting) will never be long.
> > autocommit is however set to 1 now. Thanks for the advice.
> >
> > I dont' known why it freezes when maxIdle set to -1 and why it does not
> > when
> > maxIdle is set to 0. But if i well guess, 0 closes usable connections,
> > that's it ?! So it's not optimized.
> >
>
> You enabled whenExhaustedAction="1" this mean that the pool blocks till
> a connection was returned. Max active connections is set to 5 this isn't
> much for a mulithreaded application. Maybe your application cause a
> deadlock, five different broker instances exhaust the pool and another
> broker instance try to lookup a connection but other broker instances
> still not closed.
> What happens when you set whenExhaustedAction="0"?
>
> I think if you set maxIdle=0 only one connection or none connections
> will remain in the pool (maybe I'm wrong, I don't check commons-pool
> sources) and all access is "serialized" by this.
>
> regards,
> Armin
>
>
> > Here's my well working conn setup
> >
> > Regards.
> >
> >
> > <connection-pool
> > maxActive="5"
> > maxIdle="0"
> > minIdle="2"
> > maxWait="1000"
> > whenExhaustedAction="1"
> >
> > validationQuery="SELECT CURRENT_TIMESTAMP"
> > testOnBorrow="true"
> > testOnReturn="false"
> > testWhileIdle="true"
> > timeBetweenEvictionRunsMillis="60000"
> > numTestsPerEvictionRun="2"
> > minEvictableIdleTimeMillis="1800000"
> > removedAbandonned="false"
> > removeAbandonedTimeout="300"
> > logAbandoned="true">
> >
> > <!-- Set fetchSize to 0 to use driver's default. -->
> > <attribute attribute-name="fetchSize" attribute-value="0"/>
> >
> > <!-- Attributes with name prefix "jdbc." are passed directly
> to
> > the JDBC driver. -->
> > <!-- Example setting (used by Oracle driver when Statement
> > batching is enabled) -->
> > <attribute attribute-name="jdbc.defaultBatchValue"
> > attribute-value="5"/>
> >
> > <!-- Attributes determining if ConnectionFactoryDBCPImpl
> > should also pool PreparedStatement. This is
> > programmatically disabled
> > when using platform=Oracle9i since Oracle statement
> caching
> > will conflict
> > with DBCP ObjectPool-based PreparepdStatement caching
> (ie
> > setting true
> > here has no effect for Oracle9i platform). -->
> > <attribute attribute-name="dbcp.poolPreparedStatements"
> > attribute-value="false"/>
> > <attribute attribute-name="dbcp.maxOpenPreparedStatements"
> > attribute-value="10"/>
> > <!-- Attribute determining if the Commons DBCP connection
> > wrapper will allow
> > access to the underlying concrete Connection instance
> from
> > the JDBC-driver
> > (normally this is not allowed, like in J2EE-containers
> > using wrappers). -->
> > <attribute attribute-name="
> > dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
> > </connection-pool>
> >
> >
> >
> >
> >
> >
> >
> > On 5/6/06, Armin Waibel <ar...@apache.org> wrote:
> >>
> >> Hi Bruno,
> >>
> >> Bruno CROS wrote:
> >> > Hi Armin,
> >> >
> >> > In fact, i looked at the DB connections in the DB console. It was a
> bad
> >> > idea, because connection disappear !! I looked with netstat -a , and
> i
> >> saw
> >> > several sockets/connections...
> >> >
> >> > Well, i was experiencing some freezes with these connections with a
> >> pool
> >> > setup maxActive set to -1. I didn't find any documentation on that
> >> value.
> >>
> >> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
> >> commons-pool to manage connections. There you can find details about
> the
> >> settings
> >> http://jakarta.apache.org/commons/pool/apidocs/index.html
> >>
> >> I would recommend to set maxActive connections at most to the maximal
> >> connections provided by your database server.
> >>
> >>
> >> > What i known is that, when i put 0 (no limit), it seems there is no
> >> more
> >> > freeze.
> >> >
> >>
> >> I think there is a typo in documentation. For unlimited connection pool
> >> you have to set -1.
> >>
> >>
> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
> >>
> >> Will fix this till next release.
> >>
> >> In your jdbc-connection-descriptor (posted some time ago) you set
> >> useAutoCommit="0". In this case you have to enable autoCommit 'false'
> in
> >> your jdbc-driver configuration setup, else you will run into rollback
> >> hassle (if autoCommit is 'true' for connections).
> >>
> >> regards,
> >> Armin
> >>
> >> > Can you ligth up me about that.
> >> >
> >> > Thanks.
> >> >
> >> > Regards.
> >> >
> >> >
> >> >
> >> > On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
> >> >>
> >> >> Hi Bruno,
> >> >>
> >> >> Bruno CROS wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I have a strange behaviour about the second database i use. It
> >> seems
> >> >> that
> >> >> > using "broker =
> >> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> >> >> > always return the same broker/connection.
> >> >> >
> >> >> > My connection pool is setup as it have to keep 2 idle connections
> >> >> > available, and it never occured. Still only one.
> >> >> >
> >> >> > How can i use several connection in this case?
> >> >> >
> >> >> > Note that this database is not not use to update datas. No
> >> transaction
> >> >> are
> >> >> > used on it.
> >> >> >
> >> >>
> >> >> how do you test this behavior? Please setup a test and lookup for
> two
> >> PB
> >> >> instances at the same time:
> >> >>
> >> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker
> ("rushDb");
> >> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker
> ("rushDb");
> >> >>
> >> >> Are A and B really the same broker instances? If you execute a
> >> query on
> >> >> both broker instances (don't close the broker after it) and then
> >> lookup
> >> >> the Connection from A and B - are the connections the same?
> >> >>
> >> >> regards,
> >> >> Armin
> >> >>
> >> >> >
> >> >> > Thanks.
> >> >> >
> >> >> >
> >> >> > Here's my connection setup.
> >> >> >
> >> >> > <jdbc-connection-descriptor
> >> >> > jcd-alias="rushDb"
> >> >> > default-connection="false"
> >> >> > platform="MsSQLServer"
> >> >> > jdbc-level="2.0"
> >> >> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
> >> >> > protocol="JDBC"
> >> >> > subprotocol="microsoft:sqlserver"
> >> >> > dbalias="//xxx.x.x.x:1433"
> >> >> > username="xxxx"
> >> >> > password="xxxx"
> >> >> > batch-mode="true"
> >> >> > useAutoCommit="0"
> >> >> > ignoreAutoCommitExceptions="true"
> >> >> > >
> >> >> >
> >> >> > and pool setup :
> >> >> >
> >> >> > maxActive="5"
> >> >> > maxIdle="-1"
> >> >> > minIdle="2"
> >> >> > maxWait="5000"
> >> >> > whenExhaustedAction="2"
> >> >> >
> >> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
> >> >> > testOnBorrow="true"
> >> >> > testOnReturn="false"
> >> >> > testWhileIdle="true"
> >> >> > timeBetweenEvictionRunsMillis="60000"
> >> >> > numTestsPerEvictionRun="2"
> >> >> > minEvictableIdleTimeMillis="1800000"
> >> >> > removedAbandonned="false"
> >> >> > removeAbandonedTimeout="300"
> >> >> > logAbandoned="true">
> >> >> >
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> 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
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: Only one PB from second database
Posted by Armin Waibel <ar...@apache.org>.
Bruno CROS wrote:
> Hi Armin,
>
> autoCommit set to 1 does not avoid freeze. The fact is that database is
> only
> used to be read, so rollbacks ( by disconnecting) will never be long.
> autocommit is however set to 1 now. Thanks for the advice.
>
> I dont' known why it freezes when maxIdle set to -1 and why it does not
> when
> maxIdle is set to 0. But if i well guess, 0 closes usable connections,
> that's it ?! So it's not optimized.
>
You enabled whenExhaustedAction="1" this mean that the pool blocks till
a connection was returned. Max active connections is set to 5 this isn't
much for a mulithreaded application. Maybe your application cause a
deadlock, five different broker instances exhaust the pool and another
broker instance try to lookup a connection but other broker instances
still not closed.
What happens when you set whenExhaustedAction="0"?
I think if you set maxIdle=0 only one connection or none connections
will remain in the pool (maybe I'm wrong, I don't check commons-pool
sources) and all access is "serialized" by this.
regards,
Armin
> Here's my well working conn setup
>
> Regards.
>
>
> <connection-pool
> maxActive="5"
> maxIdle="0"
> minIdle="2"
> maxWait="1000"
> whenExhaustedAction="1"
>
> validationQuery="SELECT CURRENT_TIMESTAMP"
> testOnBorrow="true"
> testOnReturn="false"
> testWhileIdle="true"
> timeBetweenEvictionRunsMillis="60000"
> numTestsPerEvictionRun="2"
> minEvictableIdleTimeMillis="1800000"
> removedAbandonned="false"
> removeAbandonedTimeout="300"
> logAbandoned="true">
>
> <!-- Set fetchSize to 0 to use driver's default. -->
> <attribute attribute-name="fetchSize" attribute-value="0"/>
>
> <!-- Attributes with name prefix "jdbc." are passed directly to
> the JDBC driver. -->
> <!-- Example setting (used by Oracle driver when Statement
> batching is enabled) -->
> <attribute attribute-name="jdbc.defaultBatchValue"
> attribute-value="5"/>
>
> <!-- Attributes determining if ConnectionFactoryDBCPImpl
> should also pool PreparedStatement. This is
> programmatically disabled
> when using platform=Oracle9i since Oracle statement caching
> will conflict
> with DBCP ObjectPool-based PreparepdStatement caching (ie
> setting true
> here has no effect for Oracle9i platform). -->
> <attribute attribute-name="dbcp.poolPreparedStatements"
> attribute-value="false"/>
> <attribute attribute-name="dbcp.maxOpenPreparedStatements"
> attribute-value="10"/>
> <!-- Attribute determining if the Commons DBCP connection
> wrapper will allow
> access to the underlying concrete Connection instance from
> the JDBC-driver
> (normally this is not allowed, like in J2EE-containers
> using wrappers). -->
> <attribute attribute-name="
> dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
> </connection-pool>
>
>
>
>
>
>
>
> On 5/6/06, Armin Waibel <ar...@apache.org> wrote:
>>
>> Hi Bruno,
>>
>> Bruno CROS wrote:
>> > Hi Armin,
>> >
>> > In fact, i looked at the DB connections in the DB console. It was a bad
>> > idea, because connection disappear !! I looked with netstat -a , and i
>> saw
>> > several sockets/connections...
>> >
>> > Well, i was experiencing some freezes with these connections with a
>> pool
>> > setup maxActive set to -1. I didn't find any documentation on that
>> value.
>>
>> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
>> commons-pool to manage connections. There you can find details about the
>> settings
>> http://jakarta.apache.org/commons/pool/apidocs/index.html
>>
>> I would recommend to set maxActive connections at most to the maximal
>> connections provided by your database server.
>>
>>
>> > What i known is that, when i put 0 (no limit), it seems there is no
>> more
>> > freeze.
>> >
>>
>> I think there is a typo in documentation. For unlimited connection pool
>> you have to set -1.
>>
>> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
>>
>> Will fix this till next release.
>>
>> In your jdbc-connection-descriptor (posted some time ago) you set
>> useAutoCommit="0". In this case you have to enable autoCommit 'false' in
>> your jdbc-driver configuration setup, else you will run into rollback
>> hassle (if autoCommit is 'true' for connections).
>>
>> regards,
>> Armin
>>
>> > Can you ligth up me about that.
>> >
>> > Thanks.
>> >
>> > Regards.
>> >
>> >
>> >
>> > On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
>> >>
>> >> Hi Bruno,
>> >>
>> >> Bruno CROS wrote:
>> >> > Hi,
>> >> >
>> >> > I have a strange behaviour about the second database i use. It
>> seems
>> >> that
>> >> > using "broker =
>> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> >> > always return the same broker/connection.
>> >> >
>> >> > My connection pool is setup as it have to keep 2 idle connections
>> >> > available, and it never occured. Still only one.
>> >> >
>> >> > How can i use several connection in this case?
>> >> >
>> >> > Note that this database is not not use to update datas. No
>> transaction
>> >> are
>> >> > used on it.
>> >> >
>> >>
>> >> how do you test this behavior? Please setup a test and lookup for two
>> PB
>> >> instances at the same time:
>> >>
>> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>> >>
>> >> Are A and B really the same broker instances? If you execute a
>> query on
>> >> both broker instances (don't close the broker after it) and then
>> lookup
>> >> the Connection from A and B - are the connections the same?
>> >>
>> >> regards,
>> >> Armin
>> >>
>> >> >
>> >> > Thanks.
>> >> >
>> >> >
>> >> > Here's my connection setup.
>> >> >
>> >> > <jdbc-connection-descriptor
>> >> > jcd-alias="rushDb"
>> >> > default-connection="false"
>> >> > platform="MsSQLServer"
>> >> > jdbc-level="2.0"
>> >> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
>> >> > protocol="JDBC"
>> >> > subprotocol="microsoft:sqlserver"
>> >> > dbalias="//xxx.x.x.x:1433"
>> >> > username="xxxx"
>> >> > password="xxxx"
>> >> > batch-mode="true"
>> >> > useAutoCommit="0"
>> >> > ignoreAutoCommitExceptions="true"
>> >> > >
>> >> >
>> >> > and pool setup :
>> >> >
>> >> > maxActive="5"
>> >> > maxIdle="-1"
>> >> > minIdle="2"
>> >> > maxWait="5000"
>> >> > whenExhaustedAction="2"
>> >> >
>> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
>> >> > testOnBorrow="true"
>> >> > testOnReturn="false"
>> >> > testWhileIdle="true"
>> >> > timeBetweenEvictionRunsMillis="60000"
>> >> > numTestsPerEvictionRun="2"
>> >> > minEvictableIdleTimeMillis="1800000"
>> >> > removedAbandonned="false"
>> >> > removeAbandonedTimeout="300"
>> >> > logAbandoned="true">
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Only one PB from second database
Posted by Bruno CROS <br...@gmail.com>.
Hi Armin,
autoCommit set to 1 does not avoid freeze. The fact is that database is only
used to be read, so rollbacks ( by disconnecting) will never be long.
autocommit is however set to 1 now. Thanks for the advice.
I dont' known why it freezes when maxIdle set to -1 and why it does not when
maxIdle is set to 0. But if i well guess, 0 closes usable connections,
that's it ?! So it's not optimized.
Here's my well working conn setup
Regards.
<connection-pool
maxActive="5"
maxIdle="0"
minIdle="2"
maxWait="1000"
whenExhaustedAction="1"
validationQuery="SELECT CURRENT_TIMESTAMP"
testOnBorrow="true"
testOnReturn="false"
testWhileIdle="true"
timeBetweenEvictionRunsMillis="60000"
numTestsPerEvictionRun="2"
minEvictableIdleTimeMillis="1800000"
removedAbandonned="false"
removeAbandonedTimeout="300"
logAbandoned="true">
<!-- Set fetchSize to 0 to use driver's default. -->
<attribute attribute-name="fetchSize" attribute-value="0"/>
<!-- Attributes with name prefix "jdbc." are passed directly to
the JDBC driver. -->
<!-- Example setting (used by Oracle driver when Statement
batching is enabled) -->
<attribute attribute-name="jdbc.defaultBatchValue"
attribute-value="5"/>
<!-- Attributes determining if ConnectionFactoryDBCPImpl
should also pool PreparedStatement. This is
programmatically disabled
when using platform=Oracle9i since Oracle statement caching
will conflict
with DBCP ObjectPool-based PreparepdStatement caching (ie
setting true
here has no effect for Oracle9i platform). -->
<attribute attribute-name="dbcp.poolPreparedStatements"
attribute-value="false"/>
<attribute attribute-name="dbcp.maxOpenPreparedStatements"
attribute-value="10"/>
<!-- Attribute determining if the Commons DBCP connection
wrapper will allow
access to the underlying concrete Connection instance from
the JDBC-driver
(normally this is not allowed, like in J2EE-containers
using wrappers). -->
<attribute attribute-name="
dbcp.accessToUnderlyingConnectionAllowed" attribute-value="false"/>
</connection-pool>
On 5/6/06, Armin Waibel <ar...@apache.org> wrote:
>
> Hi Bruno,
>
> Bruno CROS wrote:
> > Hi Armin,
> >
> > In fact, i looked at the DB connections in the DB console. It was a bad
> > idea, because connection disappear !! I looked with netstat -a , and i
> saw
> > several sockets/connections...
> >
> > Well, i was experiencing some freezes with these connections with a pool
> > setup maxActive set to -1. I didn't find any documentation on that
> value.
>
> Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
> commons-pool to manage connections. There you can find details about the
> settings
> http://jakarta.apache.org/commons/pool/apidocs/index.html
>
> I would recommend to set maxActive connections at most to the maximal
> connections provided by your database server.
>
>
> > What i known is that, when i put 0 (no limit), it seems there is no more
> > freeze.
> >
>
> I think there is a typo in documentation. For unlimited connection pool
> you have to set -1.
>
> http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
> Will fix this till next release.
>
> In your jdbc-connection-descriptor (posted some time ago) you set
> useAutoCommit="0". In this case you have to enable autoCommit 'false' in
> your jdbc-driver configuration setup, else you will run into rollback
> hassle (if autoCommit is 'true' for connections).
>
> regards,
> Armin
>
> > Can you ligth up me about that.
> >
> > Thanks.
> >
> > Regards.
> >
> >
> >
> > On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
> >>
> >> Hi Bruno,
> >>
> >> Bruno CROS wrote:
> >> > Hi,
> >> >
> >> > I have a strange behaviour about the second database i use. It seems
> >> that
> >> > using "broker =
> >> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> >> > always return the same broker/connection.
> >> >
> >> > My connection pool is setup as it have to keep 2 idle connections
> >> > available, and it never occured. Still only one.
> >> >
> >> > How can i use several connection in this case?
> >> >
> >> > Note that this database is not not use to update datas. No
> transaction
> >> are
> >> > used on it.
> >> >
> >>
> >> how do you test this behavior? Please setup a test and lookup for two
> PB
> >> instances at the same time:
> >>
> >> broker_A = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
> >> broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
> >>
> >> Are A and B really the same broker instances? If you execute a query on
> >> both broker instances (don't close the broker after it) and then lookup
> >> the Connection from A and B - are the connections the same?
> >>
> >> regards,
> >> Armin
> >>
> >> >
> >> > Thanks.
> >> >
> >> >
> >> > Here's my connection setup.
> >> >
> >> > <jdbc-connection-descriptor
> >> > jcd-alias="rushDb"
> >> > default-connection="false"
> >> > platform="MsSQLServer"
> >> > jdbc-level="2.0"
> >> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
> >> > protocol="JDBC"
> >> > subprotocol="microsoft:sqlserver"
> >> > dbalias="//xxx.x.x.x:1433"
> >> > username="xxxx"
> >> > password="xxxx"
> >> > batch-mode="true"
> >> > useAutoCommit="0"
> >> > ignoreAutoCommitExceptions="true"
> >> > >
> >> >
> >> > and pool setup :
> >> >
> >> > maxActive="5"
> >> > maxIdle="-1"
> >> > minIdle="2"
> >> > maxWait="5000"
> >> > whenExhaustedAction="2"
> >> >
> >> > validationQuery="SELECT CURRENT_TIMESTAMP"
> >> > testOnBorrow="true"
> >> > testOnReturn="false"
> >> > testWhileIdle="true"
> >> > timeBetweenEvictionRunsMillis="60000"
> >> > numTestsPerEvictionRun="2"
> >> > minEvictableIdleTimeMillis="1800000"
> >> > removedAbandonned="false"
> >> > removeAbandonedTimeout="300"
> >> > logAbandoned="true">
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: Only one PB from second database
Posted by Armin Waibel <ar...@apache.org>.
Hi Bruno,
Bruno CROS wrote:
> Hi Armin,
>
> In fact, i looked at the DB connections in the DB console. It was a bad
> idea, because connection disappear !! I looked with netstat -a , and i saw
> several sockets/connections...
>
> Well, i was experiencing some freezes with these connections with a pool
> setup maxActive set to -1. I didn't find any documentation on that value.
Both ConnectionFactoryPooledImpl and ConnectionFactoryDBCPImpl use
commons-pool to manage connections. There you can find details about the
settings
http://jakarta.apache.org/commons/pool/apidocs/index.html
I would recommend to set maxActive connections at most to the maximal
connections provided by your database server.
> What i known is that, when i put 0 (no limit), it seems there is no more
> freeze.
>
I think there is a typo in documentation. For unlimited connection pool
you have to set -1.
http://jakarta.apache.org/commons/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html
Will fix this till next release.
In your jdbc-connection-descriptor (posted some time ago) you set
useAutoCommit="0". In this case you have to enable autoCommit 'false' in
your jdbc-driver configuration setup, else you will run into rollback
hassle (if autoCommit is 'true' for connections).
regards,
Armin
> Can you ligth up me about that.
>
> Thanks.
>
> Regards.
>
>
>
> On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
>>
>> Hi Bruno,
>>
>> Bruno CROS wrote:
>> > Hi,
>> >
>> > I have a strange behaviour about the second database i use. It seems
>> that
>> > using "broker =
>> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
>> > always return the same broker/connection.
>> >
>> > My connection pool is setup as it have to keep 2 idle connections
>> > available, and it never occured. Still only one.
>> >
>> > How can i use several connection in this case?
>> >
>> > Note that this database is not not use to update datas. No transaction
>> are
>> > used on it.
>> >
>>
>> how do you test this behavior? Please setup a test and lookup for two PB
>> instances at the same time:
>>
>> broker_A = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>> broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>>
>> Are A and B really the same broker instances? If you execute a query on
>> both broker instances (don't close the broker after it) and then lookup
>> the Connection from A and B - are the connections the same?
>>
>> regards,
>> Armin
>>
>> >
>> > Thanks.
>> >
>> >
>> > Here's my connection setup.
>> >
>> > <jdbc-connection-descriptor
>> > jcd-alias="rushDb"
>> > default-connection="false"
>> > platform="MsSQLServer"
>> > jdbc-level="2.0"
>> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
>> > protocol="JDBC"
>> > subprotocol="microsoft:sqlserver"
>> > dbalias="//xxx.x.x.x:1433"
>> > username="xxxx"
>> > password="xxxx"
>> > batch-mode="true"
>> > useAutoCommit="0"
>> > ignoreAutoCommitExceptions="true"
>> > >
>> >
>> > and pool setup :
>> >
>> > maxActive="5"
>> > maxIdle="-1"
>> > minIdle="2"
>> > maxWait="5000"
>> > whenExhaustedAction="2"
>> >
>> > validationQuery="SELECT CURRENT_TIMESTAMP"
>> > testOnBorrow="true"
>> > testOnReturn="false"
>> > testWhileIdle="true"
>> > timeBetweenEvictionRunsMillis="60000"
>> > numTestsPerEvictionRun="2"
>> > minEvictableIdleTimeMillis="1800000"
>> > removedAbandonned="false"
>> > removeAbandonedTimeout="300"
>> > logAbandoned="true">
>> >
>>
>> ---------------------------------------------------------------------
>> 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
Re: Only one PB from second database
Posted by Bruno CROS <br...@gmail.com>.
Hi Armin,
In fact, i looked at the DB connections in the DB console. It was a bad
idea, because connection disappear !! I looked with netstat -a , and i saw
several sockets/connections...
Well, i was experiencing some freezes with these connections with a pool
setup maxActive set to -1. I didn't find any documentation on that value.
What i known is that, when i put 0 (no limit), it seems there is no more
freeze.
Can you ligth up me about that.
Thanks.
Regards.
On 5/5/06, Armin Waibel <ar...@apache.org> wrote:
>
> Hi Bruno,
>
> Bruno CROS wrote:
> > Hi,
> >
> > I have a strange behaviour about the second database i use. It seems
> that
> > using "broker =
> > PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> > always return the same broker/connection.
> >
> > My connection pool is setup as it have to keep 2 idle connections
> > available, and it never occured. Still only one.
> >
> > How can i use several connection in this case?
> >
> > Note that this database is not not use to update datas. No transaction
> are
> > used on it.
> >
>
> how do you test this behavior? Please setup a test and lookup for two PB
> instances at the same time:
>
> broker_A = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
> broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
>
> Are A and B really the same broker instances? If you execute a query on
> both broker instances (don't close the broker after it) and then lookup
> the Connection from A and B - are the connections the same?
>
> regards,
> Armin
>
> >
> > Thanks.
> >
> >
> > Here's my connection setup.
> >
> > <jdbc-connection-descriptor
> > jcd-alias="rushDb"
> > default-connection="false"
> > platform="MsSQLServer"
> > jdbc-level="2.0"
> > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
> > protocol="JDBC"
> > subprotocol="microsoft:sqlserver"
> > dbalias="//xxx.x.x.x:1433"
> > username="xxxx"
> > password="xxxx"
> > batch-mode="true"
> > useAutoCommit="0"
> > ignoreAutoCommitExceptions="true"
> > >
> >
> > and pool setup :
> >
> > maxActive="5"
> > maxIdle="-1"
> > minIdle="2"
> > maxWait="5000"
> > whenExhaustedAction="2"
> >
> > validationQuery="SELECT CURRENT_TIMESTAMP"
> > testOnBorrow="true"
> > testOnReturn="false"
> > testWhileIdle="true"
> > timeBetweenEvictionRunsMillis="60000"
> > numTestsPerEvictionRun="2"
> > minEvictableIdleTimeMillis="1800000"
> > removedAbandonned="false"
> > removeAbandonedTimeout="300"
> > logAbandoned="true">
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: Only one PB from second database
Posted by Armin Waibel <ar...@apache.org>.
Hi Bruno,
Bruno CROS wrote:
> Hi,
>
> I have a strange behaviour about the second database i use. It seems that
> using "broker =
> PersistenceBrokerFactory.createPersistenceBroker("rushDb");"
> always return the same broker/connection.
>
> My connection pool is setup as it have to keep 2 idle connections
> available, and it never occured. Still only one.
>
> How can i use several connection in this case?
>
> Note that this database is not not use to update datas. No transaction are
> used on it.
>
how do you test this behavior? Please setup a test and lookup for two PB
instances at the same time:
broker_A = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
broker_B = PersistenceBrokerFactory.createPersistenceBroker("rushDb");
Are A and B really the same broker instances? If you execute a query on
both broker instances (don't close the broker after it) and then lookup
the Connection from A and B - are the connections the same?
regards,
Armin
>
> Thanks.
>
>
> Here's my connection setup.
>
> <jdbc-connection-descriptor
> jcd-alias="rushDb"
> default-connection="false"
> platform="MsSQLServer"
> jdbc-level="2.0"
> driver="com.microsoft.jdbc.sqlserver.SQLServerDriver"
> protocol="JDBC"
> subprotocol="microsoft:sqlserver"
> dbalias="//xxx.x.x.x:1433"
> username="xxxx"
> password="xxxx"
> batch-mode="true"
> useAutoCommit="0"
> ignoreAutoCommitExceptions="true"
> >
>
> and pool setup :
>
> maxActive="5"
> maxIdle="-1"
> minIdle="2"
> maxWait="5000"
> whenExhaustedAction="2"
>
> validationQuery="SELECT CURRENT_TIMESTAMP"
> testOnBorrow="true"
> testOnReturn="false"
> testWhileIdle="true"
> timeBetweenEvictionRunsMillis="60000"
> numTestsPerEvictionRun="2"
> minEvictableIdleTimeMillis="1800000"
> removedAbandonned="false"
> removeAbandonedTimeout="300"
> logAbandoned="true">
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org