[
https://issues.apache.org/jira/browse/POOL-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909365#comment-14909365
]
Phil Steitz commented on POOL-305:
----------------------------------
If we want the test to be performed and the object destroyed when the evictor
visits it, then yes, it will be done by the evictor. I don't think it is
sufficient, though, to have it done *only* by the evictor. I think it makes
sense to do as DBCP does, which is to test on return (passivate), borrow
(activate) and validate (though I am not sure that is strictly necessary, since
the only kills you will get beyond the other two is when testWhileIdle is on
and it is the evictor doing it). Going through the code in borrowObject,
returnObject and the evictor and inserting tests before activation /
passivation is one way to go; but may be ugly and inefficient. Another thought
I had is to insert tests in DefaultPooledObject allocate and deallocate, which
would cover the non-validate cases. But that would require users to subclass
DPO to get the functionality.
Better ideas?
> 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)
