Project

Profile

Help

Forums » Open Discussion »

Implementation of key storage

Added by Anonymous about 14 years ago

Legacy ID: #8235787 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

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 http://sourceforge.net/projects/saxon/forums/forum/94027/topic/1930856, responses 11, 12 The problem is like this. If one creates a temporary document and look-ups nodes in that document using xsl:key, 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 cases: a) define a method Map<Object, Object> getIndices() over DocumentInfo (ConcurrentMap?); b) use getIndices() to store key data by key definition instead of Controller's user data.


Replies (2)

RE: Implementation of key storage - Added by Anonymous about 14 years ago

Legacy ID: #8236384 Legacy Poster: Michael Kay (mhkay)

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); } DocumentPool: 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.

RE: Implementation of key storage - Added by Anonymous about 14 years ago

Legacy ID: #8236435 Legacy Poster: Michael Kay (mhkay)

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.

    (1-2/2)

    Please register to reply