[
https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303216#comment-14303216
]
Marcel Reutegger commented on JCR-2768:
---------------------------------------
I was referring to what Jukka wrote following your quote.
The weak reference to SessionImpl would refer to the SessionContext. The latter
is the object where a release call is necessary. We don't necessarily need the
SessionImpl object to perform the release.
> Finalize method on SessionImpl
> ------------------------------
>
> Key: JCR-2768
> URL: https://issues.apache.org/jira/browse/JCR-2768
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.1
> Reporter: Douglas Britsch
>
> Doing some profiling on our application which uses Jackrabbit-2.1.0 I noticed
> that there were an awful lot of java.lang.ref.Finalizer objects hanging
> around. Digging around I found the culprit was a finalize method on
> SessionImpl. While I can see what it is trying to do (close the session if
> you have not called logout) , I have found in the past that on application
> servers, finalize should be avoided for objects that are created and deleted
> frequently, as the GC behavior and object allocation is severely impacted,
> and because of the number of references held by the session this seems like
> it could keep a lot more in memory than needed a lot longer. (for more info
> see http://www.fasterj.com/articles/finalizer1.shtml ).
> Per Jukka's suggestion on the mailing list "
> The automatic closing of a discarded session and related the warning
> message are pretty useful in practice, as there are quite a few
> session leaks in many client applications. So I'd rather keep that
> functionality.
> If the finalizer causes problems, we could investigate using weak (or
> perhaps phantom) references and a reference queue for this purpose.
> The RepositoryImpl class already keeps weak references to all sessions
> in the activeSessions map, so this shouldn't even be too difficult to
> implement."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
