[ 
https://issues.apache.org/jira/browse/SLING-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163061#comment-14163061
 ] 

Carsten Ziegeler commented on SLING-3983:
-----------------------------------------

Quoting Michael from a recent thread in Oak: " under some circumstances local 
events get aggregated such that the user data becomes unavailable (i.e. the 
commit boundaries get lost). This happens when the commit rate is too hight for 
event processing to keep up with"
This basically means you can't rely on user data which means this - simply put 
- this is useless. A feature that "usually works" but does under heavy load is 
dangerous. So unless this gets fixed in Oak we shouldn't add it.

> Make Session UserData available in OSGI Event
> ---------------------------------------------
>
>                 Key: SLING-3983
>                 URL: https://issues.apache.org/jira/browse/SLING-3983
>             Project: Sling
>          Issue Type: New Feature
>          Components: JCR
>    Affects Versions: JCR Resource 2.3.8
>            Reporter: Dominique Pfister
>            Priority: Minor
>         Attachments: patch.txt
>
>
> In my Sling/Oak server application I'm handling PUT requests from a client 
> and create appropriate JCR resources. These PUT requests carry a request ID 
> that I'd like to associate with the respective OSGI event I'll be receiving 
> some time later. Now I noticed that using the JCR API:
> Session.getWorkspace().getObservationManager().setUserData(String)
> I could store this request ID. This user data gets passed along in Oak's 
> CommitInfo (in its Info Map), which  Sling's OakResourceListener (in 
> org.apache.sling.jcr.resource.internal) receives it in its added(), deleted() 
> and changed() methods, but it currently does not package it into the OSGI 
> event it sends.
> It would be great if Sling could pass this along with the event, so I do not 
> have to create a NodeObserver/JcrEventListener of my own to catch this 
> information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to