Oops, it's me.
Sorry
On 5/11/06, Bruno CROS <[EMAIL PROTECTED]> wrote:
Yep, i 'm affraid that _pool.size() is always > than -1 !! (the maxIdle),
so "shouldDestroy" is true, and no pool is added.
May be it's me . Someone can confirm this ?
private void addObjectToPool(Object obj, boolean decrementNumActive)
throws Exception {
boolean success = true;
if(_testOnReturn && !(_factory.validateObject(obj))) {
success = false;
} else {
try {
_factory.passivateObject(obj);
} catch(Exception e) {
success = false;
}
}
boolean shouldDestroy = !success;
if (decrementNumActive) {
_numActive--;
}
if((_maxIdle >= 0) && (_pool.size() >= _maxIdle)) {
shouldDestroy = true;
} else if(success) {
_pool.addLast(new ObjectTimestampPair(obj));
}
notifyAll(); // _numActive has changed
if(shouldDestroy) {
try {
_factory.destroyObject(obj);
} catch(Exception e) {
// ignored
}
}
}
On 5/11/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>
>
>
> 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]
>
>
