[
https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918840#action_12918840
]
Jukka Zitting commented on JCR-2768:
------------------------------------
Could we use weak references instead of phantom references? When a weak
reference is queued for destruction, you can still access the referenced
object. It probably still comes with similar (if not worse) garbage collection
overhead as a finalizer, but perhaps clearing the reference when a normal
logout() is called would avoid that.
> 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.0
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.