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"
Borrow="true"
Return="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 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= since statement caching
will conflict
with DBCP Pool-based PreparepdStatement caching (ie
setting true
here has no effect for platform).
<attribute attribute-name="dbcp.poolPreparedStatements"
attribute-value="false"/>
<attribute attribute-name="PreparedStatements"
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="
" attribute-value="false"/>
</connection-pool>
5/6/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
Hi Bruno,
Bruno CRS 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
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.
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.
>
>
>
5/5/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>Hi Bruno,
>>
>Bruno CRS wrote:
>Hi,
>>
>I have a strange behaviour about the second database i use. It seems
>that
>using "broker =
>("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 = ("rushDb");
>broker_B = ("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=""
>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"
>Borrow="true"
>Return="false"
>testWhileIdle="true"
>timeBetweenEvictionRunsMillis="60000"
>numTestsPerEvictionRun="2"
>minEvictableIdleTimeMillis="1800000"
>removedAbandonned="false"
>removeAbandonedTimeout="300"
>logAbandoned="true">
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>
>
>
>
To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
--

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

5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:

Bruno CRS 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"
Borrow="true"
Return="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 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= since statement
caching
will conflict
with DBCP Pool-based PreparepdStatement caching
(ie
setting true
here has no effect for platform).
<attribute attribute-name="dbcp.poolPreparedStatements"
attribute-value="false"/>
<attribute attribute-name="PreparedStatements"
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="
" attribute-value="false"/>
</connection-pool>
>
>
>
>
>
>
>
5/6/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>Hi Bruno,
>>
>Bruno CRS 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
>
>>
>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.
>>
>>

>>
>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.
>>
>>
>>
>5/5/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>
>>Hi Bruno,
>>>
>>Bruno CRS wrote:
>>Hi,
>>>
>>I have a strange behaviour about the second database i use. It
>seems
>>that
>>using "broker =
>>("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 =
("rushDb");
>>broker_B =
("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=""
>>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"
>>Borrow="true"
>>Return="false"
>>testWhileIdle="true"
>>timeBetweenEvictionRunsMillis="60000"
>>numTestsPerEvictionRun="2"
>>minEvictableIdleTimeMillis="1800000"
>>removedAbandonned="false"
>>removeAbandonedTimeout="300"
>>logAbandoned="true">
>>>
>>>
>>>

>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>
>>>
>>
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>
>
>

To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
--

Bruno CRS 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"
Borrow="true"
Return="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 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= since statement caching
will conflict
with DBCP Pool-based PreparepdStatement caching (ie
setting true
here has no effect for platform).
<attribute attribute-name="dbcp.poolPreparedStatements"
attribute-value="false"/>
<attribute attribute-name="PreparedStatements"
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="
" attribute-value="false"/>
</connection-pool>

5/6/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>Hi Bruno,
>>
>Bruno CRS 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
>
>>
>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.
>>
>
>>
>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.
>>
>>
>>
>5/5/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>
>>Hi Bruno,
>>>
>>Bruno CRS wrote:
>>Hi,
>>>
>>I have a strange behaviour about the second database i use. It
>seems
>>that
>>using "broker =
>>("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 = ("rushDb");
>>broker_B = ("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=""
>>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"
>>Borrow="true"
>>Return="false"
>>testWhileIdle="true"
>>timeBetweenEvictionRunsMillis="60000"
>>numTestsPerEvictionRun="2"
>>minEvictableIdleTimeMillis="1800000"
>>removedAbandonned="false"
>>removeAbandonedTimeout="300"
>>logAbandoned="true">
>>>
>>>
>>
>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>
>>>
>>
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>

To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org

Bruno CRS 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.

(currently the apache svn is down due a SVN-server problem last night,
so download the sources).

regards,
Armin

regards

5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>Bruno CRS 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"
>Borrow="true"
>Return="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 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= since statement
>caching
>will conflict
>with DBCP Pool-based PreparepdStatement caching
>(ie
>setting true
>here has no effect for platform).
><attribute attribute-name="dbcp.poolPreparedStatements"
>attribute-value="false"/>
><attribute attribute-name="PreparedStatements"
>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="
>" attribute-value="false"/>
></connection-pool>
>>
>>
>>
>>
>>
>>
>>
>5/6/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>
>>Hi Bruno,
>>>
>>Bruno CRS 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
>>
>>>
>>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.
>>>
>>>
>
>>
>>>
>>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.
>>>
>>>
>>>
>>5/5/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>>
>>>Hi Bruno,
>>>>
>>>Bruno CRS wrote:
>>>Hi,
>>>>
>>>I have a strange behaviour about the second database i use. It
>>seems
>>>that
>>>using "broker =
>>>("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 =
>("rushDb");
>>>broker_B =
>("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=""
>>>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"
>>>Borrow="true"
>>>Return="false"
>>>testWhileIdle="true"
>>>timeBetweenEvictionRunsMillis="60000"
>>>numTestsPerEvictionRun="2"
>>>minEvictableIdleTimeMillis="1800000"
>>>removedAbandonned="false"
>>>removeAbandonedTimeout="300"
>>>logAbandoned="true">
>>>>
>>>>
>>>>
>
>>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>>
>>>>
>>>
>>>
>>>
>>
>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>
>>>
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>

To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org

No idea. All is ok on paper!

5/11/06, Bruno CRS <bruno.cros (AT) gmail (DOT) comwrote:

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
>
>
>
>
>
5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:

Bruno CRS 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"
Borrow="true"
Return="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 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= since statement
caching
will conflict
with DBCP Pool-based PreparepdStatement caching
(ie
setting true
here has no effect for platform).
<attribute attribute-name=" dbcp.poolPreparedStatements"
attribute-value="false"/>
<attribute attribute-name="PreparedStatements"
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="
" attribute-value="false"/>
</connection-pool>
>
>
>
>
>
>
>
5/6/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>Hi Bruno,
>>
>Bruno CRS 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
>
>>
>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.
>>
>
>
>>
>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.
>>
>>
>>
>5/5/06, Armin Waibel <arminw (AT) apache (DOT) org wrote:
>>>
>>Hi Bruno,
>>>
>>Bruno CRS wrote:
>>Hi,
>>>
>>I have a strange behaviour about the second database i use. It
>seems
>>that
>>using "broker =
>>("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 =
("rushDb");
>>broker_B = ("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=" "
>>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"
>>Borrow="true"
>>Return="false"
>>testWhileIdle="true"
>>timeBetweenEvictionRunsMillis="60000"
>>numTestsPerEvictionRun="2"
>>minEvictableIdleTimeMillis="1800000"
>>removedAbandonned="false"
>>removeAbandonedTimeout="300"
>>logAbandoned="true">
>>>
>>>
>>>

>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>
>>>
>>
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>
>
>

To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>
>
>

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 ToPool( obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(Return && !((obj))) {
success = false;
} else {
try {
(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 TimestampPair(obj));
}
notifyAll(); // _numActive has changed

if(shouldDestroy) {
try {
(obj);
} catch(Exception e) {
// ignored
}
}
}

5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>
>
>
Bruno CRS 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.

(currently the apache svn is down due a SVN-server problem last night,
so download the sources).

regards,
Armin
--
regards
>
>
>
>
>
5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>Bruno CRS 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"
>Borrow="true"
>Return="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 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= since statement
>caching
>will conflict
>with DBCP Pool-based PreparepdStatement caching
>(ie
>setting true
>here has no effect for platform).
><attribute attribute-name="dbcp.poolPreparedStatements"
>attribute-value="false"/>
><attribute attribute-name="PreparedStatements"
>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="
>" attribute-value="false"/>
></connection-pool>
>>
>>
>>
>>
>>
>>
>>
>5/6/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>
>>Hi Bruno,
>>>
>>Bruno CRS 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
>>
>>>
>>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.
>>>
>>>
>>

>>
>>>
>>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.
>>>
>>>
>>>
>>5/5/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>>
>>>Hi Bruno,
>>>>
>>>Bruno CRS wrote:
>>>Hi,
>>>>
>>>I have a strange behaviour about the second database i use. It
>>seems
>>>that
>>>using "broker =
>>>("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 =
>("rushDb");
>>>broker_B =
>("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=""
>>>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"
>>>Borrow="true"
>>>Return="false"
>>>testWhileIdle="true"
>>>timeBetweenEvictionRunsMillis="60000"
>>>numTestsPerEvictionRun="2"
>>>minEvictableIdleTimeMillis="1800000"
>>>removedAbandonned="false"
>>>removeAbandonedTimeout="300"
>>>logAbandoned="true">
>>>>
>>>>
>>>>
>
>>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>

>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>
>>>
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>
>
>

To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
--

, it's me.

Sorry

5/11/06, Bruno CRS <bruno.cros (AT) gmail (DOT) comwrote:

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 ToPool( obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(Return && !((obj))) {
success = false;
} else {
try {
(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 TimestampPair(obj));
}
notifyAll(); // _numActive has changed

if(shouldDestroy) {
try {
(obj);
} catch(Exception e) {
// ignored
}
}
}
--
5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>
>
>
Bruno CRS 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.

(currently the apache svn is down due a SVN-server problem last night,
so download the sources).

regards,
Armin
--
regards
>
>
>
>
>
5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>Bruno CRS 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"
>Borrow="true"
>Return="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 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= since statement
>caching
>will conflict
>with DBCP Pool-based PreparepdStatement
caching
>(ie
>setting true
>here has no effect for platform).
><attribute attribute-name="dbcp.poolPreparedStatements"
>attribute-value="false"/>
><attribute attribute-name="
PreparedStatements"
>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="
>" attribute-value="false"/>
></connection-pool>
>>
>>
>>
>>
>>
>>
>>
>5/6/06, Armin Waibel <arminw (AT) apache (DOT) org wrote:
>>>
>>Hi Bruno,
>>>
>>Bruno CRS 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
>>
>>>
>>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.
>>>
>>>
>
>
>>
>>>
>>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.
>>>
>>>
>>>
>>5/5/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>>
>>>Hi Bruno,
>>>>
>>>Bruno CRS wrote:
>>>Hi,
>>>>
>>>I have a strange behaviour about the second database i use.
It
>>seems
>>>that
>>>using "broker =
>>>("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 =
>("rushDb");
>>>broker_B =
>("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=" "
>>>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"
>>>Borrow="true"
>>>Return="false"
>>>testWhileIdle="true"
>>>timeBetweenEvictionRunsMillis="60000"
>>>numTestsPerEvictionRun="2"
>>>minEvictableIdleTimeMillis="1800000"
>>>removedAbandonned="false"
>>>removeAbandonedTimeout="300"
>>>logAbandoned="true">
>>>>
>>>>
>>>>
>
>>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>

>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>
>>>
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>
>
>

To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>
>
>

Bruno CRS 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 JB (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 ToPool( obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(Return && !((obj))) {
success = false;
} else {
try {
(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 TimestampPair(obj));
}
notifyAll(); // _numActive has changed

if(shouldDestroy) {
try {
(obj);
} catch(Exception e) {
// ignored
}
}
}

5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>
>>
>>
>Bruno CRS 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.
>
>(currently the apache svn is down due a SVN-server problem last night,
>so download the sources).
>>
>regards,
>Armin
>>
>>
>regards
>>
>>
>>
>>
>>
>5/11/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>
>>Bruno CRS 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"
>>Borrow="true"
>>Return="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 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= since statement
>>caching
>>will conflict
>>with DBCP Pool-based PreparepdStatement
>caching
>>(ie
>>setting true
>>here has no effect for platform).
>><attribute attribute-name="dbcp.poolPreparedStatements"
>>attribute-value="false"/>
>><attribute
>attribute-name="PreparedStatements"
>>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="
>>" attribute-value="false"/>
>></connection-pool>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>5/6/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>>
>>>Hi Bruno,
>>>>
>>>Bruno CRS 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
>>>
>>>>
>>>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.
>>>>
>>>>
>>>
>
>>
>>>
>>>>
>>>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.
>>>>
>>>>
>>>>
>>>5/5/06, Armin Waibel <arminw (AT) apache (DOT) orgwrote:
>>>>>
>>>>Hi Bruno,
>>>>>
>>>>Bruno CRS wrote:
>>>>Hi,
>>>>>
>>>>I have a strange behaviour about the second database i
>use. It
>>>seems
>>>>that
>>>>using "broker =
>>>>("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 =
>>("rushDb");
>>>>broker_B =
>>("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=""
>>>>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"
>>>>Borrow="true"
>>>>Return="false"
>>>>testWhileIdle="true"
>>>>timeBetweenEvictionRunsMillis="60000"
>>>>numTestsPerEvictionRun="2"
>>>>minEvictableIdleTimeMillis="1800000"
>>>>removedAbandonned="false"
>>>>removeAbandonedTimeout="300"
>>>>logAbandoned="true">
>>>>>
>>>>>
>>>>>
>>
>>>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>
>>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>>
>>>>
>>>
>>>
>>
>>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>>
>>>
>>
>>
>
>To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
>For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org
>>
>>

To unsubscribe, e-mail: ojb-user-unsubscribe (AT) db (DOT) apache.org
For additional commands, e-mail: ojb-user-help (AT) db (DOT) apache.org