However, storing the Node in the WikiPage is obviously just a speed
optimization. These two statements are equivalent:
m_node.getProperty("foo").getString();
and
m_engine
.getContentManager
().getJCRSession
().getRootNode().getNode(m_jcrPath).getProperty("foo").getString();
or even
m_engine
.getContentManager
().getJCRSession().getByUUID(m_uuid).getProperty("foo").getString();
I benchmarked these two. On Priha, to my great surprise, the latter
method is 25 times faster than the simple getProperty().
However, on Jackrabbit, the former is about 5 times faster.
So this is a fairly important decision which is going to have a huge
impact on the performance of JSPWiki 3.0. Unfortunately, these
results are wildly different, so it's really hard to say what the
correct solution is. One option is to find a least-common-
denominator: use the ThreadLocal method, but still mark WikiPages as
uncacheable. This allows us to change strategy without really
breaking anything in the future.
(Interestingly, getProperty() is about 3.5 times faster on Jackrabbit
than on Priha; but calling getJCRSession().getItem(path) is on the
order of 30 times faster on Priha than on Jackrabbit... Clearly
different optimization priorities (and caching strategies) there.)
/Janne
