Saxon

Synchronising this method more strongly solves the immediate problem, but I'm now having considerable doubts about the idea that the XPathEvaluator (and similarly the s9api XPathCompiler) are really thread-safe, that is, allowing multiple XPath compilations to take place concurrently.

The problem is that both classes contain an AbstractStaticContext, which contains a KeyManager, and compiling an XPath expression can add key definitions to the KeyManager without synchronization.

The ownership and shareability of the KeyManager look pretty obscure in the code.

For XSLT, there needs to be one KeyManager per compiled package. To this end the KeyManager is held in the PackageData object (which for XSLT will always be a StylesheetPackage). The KeyManager also has a reference to its PackageData object, so it looks like a one-to-one relationship.

So one wonders why the Executable also holds a KeyManager, and why the Controller gets it from the Executable. It looks as if it's only the idref() function that uses the KeyManager held in the Executable; and it looks as if it's only StylesheetPackage that puts a KeyManager in the Executable. So it looks to me as if the idref() function can go straight to getController().getExecutable().getTopLevelPackage().getKeyManager(), and avoid holding the KeyManager redundantly in the Executable.

QueryModule.getKeyManager() contains logic to ensure the Executable's KeyManager is copied into the packageData; we can eliminate that.

So this just leaves XPath; and the question is whether we want to continue ensuring that all XPath expressions compiled under a single XPathCompiler should share the same KeyManager. If we do, we have to make it thread-safe. That's what I've chosen to do.