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]
