[
https://issues.apache.org/jira/browse/OAK-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748334#comment-13748334
]
Chetan Mehrotra commented on OAK-960:
-------------------------------------
{quote}
Something along the lines of
https://github.com/mduerig/jackrabbit-oak/commit/1ec61c778396b99adfacca66454ed79e2c215c03?
{quote}
Interesting approach. One problem I see if supporting cases where more than two
sessions are involved. Consider a case involving three sessions s1,s2,s3
invoked in following order
# s1 - Does update. LAST_UPDATER = s1
# s2 - Does read. Sees the change and cleans the flag. LAST_UPDATER = null
# s3 - Does read. Checks LAST_UPDATER. Sees null and hence does not performs a
refresh
Hence in the SessionSynchronizer [1] I had to maintain a memory of the state
per session. And the state is cleared only upon request completion. One
workaround can be that we use a Map<Integer,Integer> to track the state such
that thread local variable does not have a hard reference to Oak specific
classes (only referes to JDK classes). This would avoid introducing a memory
leak. Just that we might pollute some thread (from pools) with small map. We
can ensure that map sizes are trimmed etc.
Further there is no proper way [2] to cleanup ThreadLocal values except from
within the thread that put them in there in the first place. So for such proper
cleanups you do require an interception point from where all execution code
passes. For HTTP Request Servlet Filter serves that purpose. There are ways
using reflection [3]
[1] https://gist.github.com/chetanmeh/6315991
[2] http://wiki.apache.org/tomcat/MemoryLeakProtection#ThreadLocal_leaks
[3]
https://weblogs.java.net/blog/jjviana/archive/2010/06/09/dealing-glassfish-301-memory-leak-or-threadlocal-thread-pool-bad-ide
> Provide an interceptor for SessionOperations
> --------------------------------------------
>
> Key: OAK-960
> URL: https://issues.apache.org/jira/browse/OAK-960
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, jcr
> Affects Versions: 0.8
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Priority: Minor
> Attachments: OAK-960.patch
>
>
> To support certain scenarios like
> * Logging session operation being performed
> * Coordinating refresh state among multiple session used in same thread
> It would be helpful to expose a {{SessionOperationInterceptor}} which can be
> invoked by the {{SessionDelegate}} before and after the operation is
> performed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
