Thank you for your suggestions. I have opened the following two issues to fix this problem:
https://issues.apache.org/jira/browse/OAK-2724 https://issues.apache.org/jira/browse/SLING-4585 - Joel On 07/04/15 07:58, "Angela Schreiber" <[email protected]> wrote: >Hi Michael > >I would opt for the Jackrabbit API variant. Changing the semantics >of the JCR API call is asking for severe troubles and I don't see >any additional effort for another version of the spec (in particular >since JSR 333 was never implemented in Jackrabbit or Oak). > >Extending the JackrabbitSession interface however, should be quite >painless and equally serving the purpose. > >Kind regards >Angela > >On 07/04/15 09:54, "Michael Dürig" <[email protected]> wrote: > >> >>On 7.4.15 9:00 , Joel Richard wrote: >>> Hi, >>> >>> In JcrResourceProvider.createResource (Sling) it uses fist >>> Session.itemExists to check whether an item exists and then >>> Session.getItem to retreive it. Even though the item data is cached for >>> the second call, this adds 8% overhead to the page rendering. 14% of >>>the >>> whole page rendering time is spent in itemExists. >>> >>> Sling could just only use getItem and catch the exception if the item >>>does >>> not exist. Unfortunately, this will not perform well if the resource >>> resolver is often used to read items which do not exist because >>>exceptions >>> are slow. >> >>This also bothers me for a long time now. I think it is an unfortunate >>design decision of JCR to either force clients to use Exceptions for >>flow control or to have to go through 2 API calls. >> >>> >>> Technically, the simplest solution would be to export the method >>> getItemOrNull. This method could be Oak-specfic and only be used by >>>Sling >>> when running on Oak. >>> >> >>t would at least be simple to extend the Jackrabbit API in such ways. >> >>Another approach would be to introduce sentinels representing non >>existing items. Clients could then do something along the lines of >> >>Node n = session.getNode("/foo/bar"); >>if (n == JackrabbitNode.NULL) { >> // no node at /foo/bar >>} else { >> // default case >>} >> >>We are using this pattern quite a bit within Oak reducing a lot of >>boilerplate. >> >>However retrofitting it to JCR comes with compatibility issues, which >>we'd need to address. >> >>Michael >
