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
