Hi Joel Thanks for reporting this improvement request.
I moved it to the Jackrabbit project as the API extensions must first go into the Jackrabbit API and then be implemented in the following Session implementations: - jackrabbit-core - jackrabbit-jcr2spi - oak-jcr The latter must wait until we have the Jackrabbit version in Oak parent changed to either 2.10.1-SNAPSHOT or a new Jackrabbit release. Kind regards Angela On 07/04/15 15:13, "Joel Richard" <[email protected]> wrote: >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 >>
