1 Reply Latest reply on Feb 4, 2011 9:05 AM by Randall Hauch

    Clarification: how does the InfiniSpan connector save node / properties contents

    Martin Senne Newbie

      Dear all,


      at that point I need some clarification and help.


      First, is the assumption correct, that all content of a node is stored in appropriate properties? Is the "main" content also stored in a property?


      Assuming we have a node with much binary content:


      How does the Inifispan connector behave?

      While browsing through the code, basically I found:





           * {@inheritDoc}


           * @see org.modeshape.graph.connector.base.Transaction#getWorkspace(java.lang.String,

           *      org.modeshape.graph.connector.base.Workspace)


          public InfinispanWorkspace getWorkspace( String name,

                                                   InfinispanWorkspace originalToClone ) {

              Cache<UUID, InfinispanNode> workspaceCache = repository.getCacheContainer().getCache(name);





      which implies, that the node (InfinispanNode, including all its properties and the content of the properties) is placed *as a whole* in InfiniSpan. Is this assumption right? What impact does that have for nodes with much content?

      Is there any lazy loading of properties using the InfinispanConnector available instead of retrieving the whole complete node?


      Many thanks in advance



        • 1. Clarification: how does the InfiniSpan connector save node / properties contents
          Randall Hauch Master

          I believe at this point, the Infinispan connector serializes the Node's properties and the list of UUIDs of each child into an Infinispan node. We would like to improve that and store individual properties natively in the Infinispan node, but haven't had time to do this nor think about how to store the list of child nodes. We thought about storing this pointers to the children as an ordered Map<UUID,Path.Segment>, but that has the disadvantage of storing the name in multiple places. (I think this is acceptable, because any change of child name has to come with a recalculation of the SNS index using the parent's list of children.)


          If you have any suggestions on how to make this work better, we'd love to hear it!