[
https://issues.apache.org/jira/browse/OAK-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011329#comment-15011329
]
Davide Giannella commented on OAK-2472:
---------------------------------------
I'll try to summarise as best as I can the maelstrom I have in my
head.
There's an issue I'm stuck now, with the approach we took. Sooner or
later we'll have to call the [NodeStore.merge(Builder, CommitHook,
CommitInfo)|http://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/state/NodeStore.html#merge%28org.apache.jackrabbit.oak.spi.state.NodeBuilder,%20org.apache.jackrabbit.oak.spi.commit.CommitHook,%20org.apache.jackrabbit.oak.spi.commit.CommitInfo%29]
in the scheduled task, in order to merge what it changed during
consolidation.
This give leave us with a problem that we don't have the CommitHooks
at the level we're playing and we need to know them.
In oak we have mainly four types of CommitHook: {{IndexEditor}},
{{Editor}}, {{ConflictHandler}} and {{CommitHook}} itself. The first
two are wrapped in their providers that are OSGi service as well.
I think we can leave the {{SecurityProvider}} as *not* a commit hook.
In the end of the repository construction, all them are converted into
one big {{CompositeCommitHook}}.
ConflictHandlers are automatically converted into CommitHook:
-
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L467
EditorProvider are automatically converted into CommitHook:
-
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L406
IndexEditorProvider are automatically converted into CommitHook:
-
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L620
This leave us with an "easy" answer at the question: what commit hook
should I provide? It's a Composite of all the {{List<CommitHook}} we
have in oak
-
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L136
Now we have two scenario we have to consider: OSGi apps and Plain Java
ones.
h3. Plain java
Let's start with the simple case: the plain java. If we add to Oak and
Jcr classes a method like {{CommitHook getCommitHook()}} which returns
the so far computed list of hooks we could pass it down to the
{{AtomicCounterEditorProvider}} constructor when we initialise the
repository (in the {{public Jcr(Oak)}}).
https://github.com/davidegiannella/jackrabbit-oak/blob/3d248a1663e15da46ea06fd701d79720d5e896e0/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/atomic/AtomicCounterEditorProvider.java
h3. OSGi
here things get a bit more complicated. The current implementation
fetch the required services: Scheduler and NodeStore in the
provider. However it will be safer to have the scheduled task to be
registered as an OSGi service and bind it's requirements. By OSGi
nature between the provider initiate the editor and the task gets
scheduled and executed these could change (already pencilled on my
todo list).
We can already bind with @Reference the IndexEditorProvider and
EditorProvider as they're already OSGi service. On the other hand this
leaves us without {{CommitHook}} and {{ConflictHandler}}. Questions:
- shall we expose all our CommitHook and ConflictHandler as OSGi
services?
- shall we wrap them in providers that are OSGi services?
Another doubt that is left in my head is:
- what if in the container there are any OSGi service that are
eventually *not* used during repository construction?
/cc [~mduerig], [~mreutegg]
thanks to [~fmeschbe] for the chat we had around OSGi aspects.
> Add support for atomic counters on cluster solutions
> ----------------------------------------------------
>
> Key: OAK-2472
> URL: https://issues.apache.org/jira/browse/OAK-2472
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Davide Giannella
> Assignee: Davide Giannella
> Labels: scalability
> Fix For: 1.4
>
> Attachments: atomic-counter.md
>
>
> As of OAK-2220 we added support for atomic counters in a non-clustered
> situation.
> This ticket is about covering the clustered ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
