[
https://issues.apache.org/jira/browse/OAK-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748408#comment-13748408
]
Michael Dürig commented on OAK-960:
-----------------------------------
bq. supporting cases where more than two sessions are involved...
Good catch! We should be able to deal with that by putting the {{updateCount}}
into the thread local on update operations and having each session delegate
compare its own value against that value to detect whether it needs to refresh.
This is the same pattern we successfully use in many other places already.
bq. there is no proper way to cleanup ThreadLocal values...
Yes but this shouldn't do any harm here as we only put instances of JDK classes
into the thread local. The worst thing that AFAICS can happen is a reused
thread (from a pool) causing a refresh to a session that would not refresh if
running off a fresh thread. I.e updates could leak through causing spurious
refreshes.
> 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
