[
https://issues.apache.org/jira/browse/OAK-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641554#comment-13641554
]
Michael Dürig commented on OAK-775:
-----------------------------------
bq. Here's a rough draft of what I had in mind...
Serialisation events this way means a scheduled update could block a merge.
This could be tuned by narrowing down the point of synchronisation and make
{{externalUpdate}} and {{localUpdate}} queue the respective node states for
asynchronous processing. But then we are back to queueing (although way fewer
items than in my proposal). If we can get this trade off right this looks like
a good solution.
Separating external from local events gives us space for more teaks:
* When a listener is only interested in either external or local events, above
synchronisation is not necessary and we could fall back to generating events
like it is currently done in the {{observation}} package.
* When a listener is not interested in session specific information (i.e.
{{Event.getUserId}}) we could also fall back as above.
Of course we'd need to devise a way for clients to specify such requirements
when registering event listeners.
> Implement backward compatible observation
> -----------------------------------------
>
> Key: OAK-775
> URL: https://issues.apache.org/jira/browse/OAK-775
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, jcr
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Attachments: OAK-775-isExternal.patch, OAK-775.patch
>
>
> As [discussed | http://markmail.org/message/6bqycmx6vbq7m25c] we might want
> look into implementing an alternative approach to observation, which trades
> some scalability for improved backward compatibility.
--
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
