[
https://issues.apache.org/jira/browse/POOL-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909317#comment-14909317
]
Phil Steitz commented on POOL-305:
----------------------------------
DBCP implements this in PoolableConnectionFactory's activate, passivate and
validate methods. (Have a the maxConnLifetimeMillis property of BasicDataSource
and PoolableConnectionFactory.) These methods throw exceptions on lifetime
exceeded, which cause the pool to destroy the object. That is a bit awkward and
it could be made cleaner if the feature you are proposing were implemented in
GOP. I think DBCP's semantics are good - you test when you are about to hand
out, receive back or validate an object. I guess you could add testing each
time the evictor visits an object (even with testWhileIdle turned off). My
initial take is that maxAge should be a pool property (like e.g
evictionIdleTimeMillis) and it should be tested at the PooledObject lifecyle
transitions (basically each time the pool activates, passivates or validates an
object).
> Add maxAge to pool config
> -------------------------
>
> Key: POOL-305
> URL: https://issues.apache.org/jira/browse/POOL-305
> Project: Commons Pool
> Issue Type: Improvement
> Affects Versions: 2.4.2
> Reporter: Michael Osipov
>
> In our environment, there are upper caps to session lifetime regardless how
> often the session has been busy/idle. Given that an object in a pool can
> remain for an indefinite time as long as it is used often enough, it may also
> already be invalided by the server.
> To avoid such issues, I'd like to have a {{maxAge}} property for an object,
> where eviction kicks in by default. This is the very same as in the [Tomcat
> JDBC Connection Pool|https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html].
> I am quite certain that this is possible with a custom eviction policy but I
> do think that should be available by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
