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