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