jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-689) Minimize calls to PersistenceManager
Date Fri, 16 Mar 2007 14:41:09 GMT

    [ https://issues.apache.org/jira/browse/JCR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481631
] 

Marcel Reutegger commented on JCR-689:
--------------------------------------

Martijn wrote:
> The methods "getItemState" and "hasItemState" in the SharedItemStateManager try to resolve
the given
> ItemId through three sources. Is there a particular reason for the order? If not, would
it then not be good
> to swap the second and third check (first check the virtual providers as this is all
in memory if I understand
> correctly, and then the non-virtual internal storage that might invoke the persistence
manager)?

Some virtual providers are in memory, but not the one that provides the version items. The
implementation kind of assumes that the majority of item accesses are items from the workspace
and that version items are accessed less frequently.

> Minimize calls to PersistenceManager
> ------------------------------------
>
>                 Key: JCR-689
>                 URL: https://issues.apache.org/jira/browse/JCR-689
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1
>            Reporter: Marcel Reutegger
>            Priority: Minor
>             Fix For: 1.3
>
>         Attachments: JCR-689-r492483.patch, NodeImpl-485720.patch
>
>
> In some situations the PersistenceManager is called even though it is not necessary.
> E.g. when new items are created the method NodeImpl.getOrCreateProperty() will always
check if there is an already existing property state. If the node is new the call will always
go down the full item state stack and ask the PersistenceManager if it knows the property
id. This is unnessessary because there will never exist properties in the persistence manager
for a new node that has not been saved yet.
> I propose to add a check to the method to see if  the node is new and does not yet have
a property with the given name. In that case the property can be created without further checks.
> With the patch applied the time to transiently create 1000 nodes with 4 properties each
drops from 1485 ms to 422 ms.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message