[
https://issues.apache.org/jira/browse/JCR-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637926#action_12637926
]
Dominique Pfister commented on JCR-1753:
----------------------------------------
I'm a bit concerned about the number of sync() calls that might pile up in the
end: at the moment, the sync() operation is guarded by a Mutex, roughly like
this:
mutex.acquire();
try {
doSync();
} finally {
mutex.release();
}
a lot of threads might potentially end up handling Repository.login() and
Session.refresh() and would therefore all in turn wait for each other, only to
start the sync() operation again. I'd therefore change the semantics of the
method described above to:
(1) either return immediately if a thread is already inside doSync() is already
in progress
(2) or wait for the processing thread in doSync() to finish and then return
Optionally, the wait in (2) might again be limited by a timeout in order to
avoid locking the complete system.
WDYT?
> Allow means force a Repository to synchronize with the cluster
> --------------------------------------------------------------
>
> Key: JCR-1753
> URL: https://issues.apache.org/jira/browse/JCR-1753
> Project: Jackrabbit
> Issue Type: New Feature
> Components: clustering, jackrabbit-api, jackrabbit-core
> Reporter: Micah Whitacre
> Assignee: Jukka Zitting
> Attachments: JCR-1753.tar.gz
>
>
> Based on the thread on the user mailing list I'm logging this to propose
> adding a sync() method to force cluster synchronization using the
> JackrabbitRepository extension API.
> The purpose of the method is such that in a distributed clustered environment
> sometime cluster synchronization does or has not occurred such that certain
> repositories are in a stale state. This method would provide a means to
> force a repository to update pull in possible changes made by other
> Jackrabbit repositories.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
