Implementation of key storage

  • ERROR! The markdown supplied could not be parsed correctly. Did you forget to surround a code snippet with "~~~~"?

    Hello Mr. Kay!  
    I would like to re-raise a question about a key storage that I was asking a
    couple of years ago.  
    See [,](
    responses 11, 12  
    The problem is like this.  
    If one creates a temporary document and look-ups nodes in that document using
    one introduces "document leak", which is not resolved after the temporary
    document goes out of scope.  
    This is due to that the saxon stores key data in Controller's user data, which
    persists to the end  
    of the transformation.  
    To work around the problem I have to call some obscure extension function  
    to release key data right after the end of the use of such temporary document.  
    I suggest a minimal refactoring that won't impact on performance of other use
    a) define a method Map<Object, Object> getIndices() over DocumentInfo
    b) use getIndices() to store key data by key definition instead of
    Controller's user data.
  • Michael Kay
    Michael Kay

    Sorry for dropping the ball on this one.

    I think it can be fixed by doing the setUserData() only if the document is
    present in the DocumentPool:
    KeyManager line 631:

    Controller controller = context.getController();
    if (controller.getDocumentPool().contains(doc)) {
    context.getController().setUserData(doc, "key-index-list", indexList);


    public boolean contains(DocumentInfo doc) {
    return documentNameMap.values().contains(doc);

    I have made this change in the development branch. It's one of those changes
    that's almost impossible to test; if there's something that I've overlooked in
    the code, then it will be overlooked in any tests as well. I'll just have to
    rely on regression testing.

  • Michael Kay
    Michael Kay

    No, on reflection I don't think this is good enough. It means that the index
    for a temporary tree (or a document that has been discarded from the document
    pool) is eligible for garbage collection between one call of key() and the
    next. I think we have to do what the comment (KeyManager line 92) suggests:
    create a firm reference from the DocumentInfo to the index. I think I have to
    bite the bullet on this and extend the DocumentInfo interface.