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 <[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]
