Daniel Jackson wrote:
I'm trying to implement some sort of caching in a system I'm writing using
the XMLGrammarPool.
What I tried so far was to create a GrammarResolver, extract it's
XMLGrammarPool and give that to the parsers I create (DOM and SAX). I
configure the parser to cache schemas during parsing so the pool gets filled
when my parser resolves external entities.
I still have several open issues though:
1. When the parser resolves 2 schemas with the same namespace, how are those
stored inside the pool? I peeked at the implementation and noticed it uses
the target namespace as it's key.
You can't store two different schemas with the same target namespace URI
in the same grammar pool. As you've noticed, this is because the pool
uses the target namespace URI as the key. It works this way because
that's how the parser finds a grammar for a particular element during
validation -- it uses the namespace URI of the element to validate.
2. Is there a way to retrieve a schema from the pool using the system id
that was given to it when it was being resolved?
No.
3. I want the achieve thread-safety when attaching the pool to a parser and
adding grammars to it. I saw that the pool provides 2 methods, lock and
unlock although I believe that those are not the ones I'm after. After
trying to use them between calls to loadGrammar I saw that it simply stops
adding grammars to the pool.
lock() allows for thread-safe reads, but not writes, because it prevents
adding new grammars and implements a thread-safe XMLStringPool.
However, you need to be very careful with using lock() and unlock()
since these member functions are not thread-safe themselves. The use
case is to add a bunch of grammars, lock it to ensure the pool is not
mutated, then allow multiple threads to have read-only access to it. In
particular, you should never lock or unlock a grammar pool after you've
given it to a parser instance.
If you really want a fully thread-safe grammar pool, you'll have to wrap
the existing pool and use a mutex to synchronize the public member
functions.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
