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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
