How do I use XPath in a thread-safe and efficient manner?

user_201891 0
Viewed 2699

(A similar question has been asked here, Java XPathFactory thread-safety, but the given answer is incorrect because it ignores the fact that the documentation states that XPathFactory.newInstance() isn't thread-safe.)

From the XPathFactory Javadoc, we have:

The XPathFactory class is not thread-safe. In other words, it is the application's responsibility to ensure that at most one thread is using a XPathFactory object at any given moment. Implementations are encouraged to mark methods as synchronized to protect themselves from broken clients.

XPathFactory is not re-entrant. While one of the newInstance methods is being invoked, applications may not attempt to recursively invoke a newInstance method, even from the same thread.

So from the above quote, I take it that XPathFactory.newInstance() (a static method) should not be called concurrently. It is not thread-safe.

The factory returns XPath objects, which has this XPath Javadoc:

An XPath object is not thread-safe and not reentrant. In other words, it is the application's responsibility to make sure that one XPath object is not used from more than one thread at any given time, and while the evaluate method is invoked, applications may not recursively call the evaluate method.

From the above quote, I take it that XPath.evaluate and XPathExpression.evaluate should not be called concurrently. They are not thread-safe.

Normally when I'm dealing with classes that aren't thread-safe I just use local variables, but because XPathFactory.newInstance() isn't thread-safe, and it's a static method, I'm not sure how to use it safely and efficiently. I guess I could synchronize calls to newInstance, but I worry about performance because my application is an XML message routing application. (In my smoke tests of newInstance it takes ~0.4 milliseconds.)

I can't find any examples of use Java XPath in a thread-safe manner, and I'm not confident I know how to use XPath in a thread-safe but efficient manner. I also have the constraint that I need to use XPath inside a singleton (specifically an Apache Camel Processor).

xpath multithreading java
3 Answers

I take it that XPathFactory.newInstance() (a static method) should not be called concurrently. It is not thread-safe.

That documentation could be interpreted differently: thread-safety and reentrancy are distinct attributes, so it is possible for XPathFactory.newInstance() to be thread-safe yet non-reentrant. The word recursively seems key; but the sentence structure is difficult to parse. Without reviewing the code in minute detail, synchronization around any newInstance calls seems the only safe way to use them. Note that Java 9 added the newDefaultInstance method, which appears trivially thread-safe.

I take it that XPath.evaluate and XPathExpression.evaluate should not be called concurrently. They are not thread-safe.

Agreed. The documentation clearly states these methods are neither thread-safe nor reentrant.

user_13713290

You could abandon the JAXP/DOM world and move to Saxon, where multithreading is much more carefully incorporated into the API design:

  • Unlike the DOM, the Saxon native tree implementations are thread-safe once document building is complete. You also get XPath 3.1 as a bonus.

  • An XPathCompiler is thread-safe once configured using its setter methods

  • An XPathExpression (created by compiling an expression using an XPathCompiler) is thread-safe (it can be executed concurrently in multiple threads)

  • An XPathSelector (formed by loading an XPathExpression) is not thread-safe; it should only be evaluated once.

user_4154480

The documentation seems to focus on objects, not newInstance calls. Here are the parts you’ve quoted; I have added some emphasis:

The XPathFactory class is not thread-safe. In other words, it is the application's responsibility to ensure that at most one thread is using a XPathFactory object at any given moment.

And:

An XPath object is not thread-safe and not reentrant.

Notice that it is referring to existing objects. XPathFactory.newInstance is a static method; it does not operate on an existing XPathFactory object. At the moment it is called, there is no object to potentially share between threads.

The documentation is stating that non-static methods of existing XPath and XPathFactory objects are not thread-safe. It is not saying that you can’t create them in different threads, only that you can’t use an object in different threads (unless you protect that usage with synchronization or Locks).

Update: It’s possible that “While one of the newInstance methods is being invoked, applications may not attempt to recursively invoke a newInstance method” may refer to concurrent XPathFactory.newInstance calls, but I take the presence of “recursively” to mean that a particular newInstance call may not invoke another call to newInstance. This theoretically can happen if you invoke the three-argument newInstance method with name of a factory class which itself attempts to call newInstance.

user_18319870
Related