|
David, To answer the question, I don’t
think the service implementation object is ever really freed from the pool once
it’s instantiated. The “pool” in this case is simply an
ArrayList. The pooling algorithm is very rudimentary. Once the
object is no longer needed by the current thread, it’s just added back to
the pool. There’s nothing that I can tell that evicts idle objects from
the pool. You could look into creating a more robust implementation by
extending PooledServiceModel yourself or put an issue out in JIRA for it.
I know that we’re reluctant to have too many dependencies for HM, so
adding a dependency to commons-pool would probably be vetoed (but you’d
have my vote). I’ve tried to suggest refactoring some of the code
so that it uses commons-beanutils, but that was quickly rejected. James From: James Carman
[mailto:[EMAIL PROTECTED] --> That’s not his question. He wants to know when the
object will be freed/evicted from the pool so that it is even eligible for gc. From: belaran [mailto:[EMAIL PROTECTED] As far as I
understand the garbage collector, there is no real way to know. At some point,
the garbage collector enters in action, degrades the perf but clean all object
that are no longer referenced... Period. 2005/7/8, David J. M. Karlsen <[EMAIL PROTECTED]>: Hi all!
|
- Eviction of pooled services David J. M. Karlsen
- Re: Eviction of pooled services belaran
- RE: Eviction of pooled services James Carman
- Re: Eviction of pooled services belaran
- RE: Eviction of pooled services James Carman
- Re: Eviction of pooled services David J. M. Karlsen
- Re: Eviction of pooled services David J. M. Karlsen
