Am 24.07.15 um 09:08 schrieb Konrad Windszus: > Hi Carsten, > thanks a lot for your answer. There is one question remaining though: > Given that you don’t want to pass the resource resolver from the client, > under which circumstances would you pick which one from the following two > approaches: > > a) Create a resource resolver in the activate method and release in the > deactivate (and live with the drawback that concurrent read access is then > synchronised and the session is open for a very long time, > https://issues.apache.org/jira/browse/OAK-2045 > <https://issues.apache.org/jira/browse/OAK-2045>). I have seen this pattern a > lot in the past. > b) Create the resource resolver on demand for each call. > > How big is the overhead to create new resolvers on demand? > At least in Jackrabbit 2 there is the drawback that those aren’t GCed quickly > enough due to their finalizers > (https://issues.apache.org/jira/browse/JCR-2768 > <https://issues.apache.org/jira/browse/JCR-2768>) > What about Oak? How big is the overhead there?
I would always go for b), it's the cleaner solution, in the end sync'ing can be more painful than the cost of creating a session. And with long running sessions , you need to refresh them etc. For your other question about the thread context resource resolver: that one allows access to the current user RR. It does not give access to an admin or service RR. The reason behind it is, that there are some cases where an implementation needs to run within the user contexts however the layers / apis between that code and the code in Sling which has the RR is not transporting the RR down. Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
