commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <>
Subject Re: JXPath: Thread-Safe Behavior and Real-Time Applications
Date Thu, 28 Oct 2004 21:14:14 GMT
JXPath is thread safe.  It has been tested extensively in multi-threaded environments.
That said, you might want to pay special attention to its performance.  The main performance
tweaking mechanism is Compiled Expressions. JXPath maintains a global cache of those.  Since
that cache is of limited size and is shared by all threads, the performance may suffer when
all these threads start storing their load of XPaths in that cache. What I would recommend
is disabling the automatic caching (for that there is a global variable on JXPathContextImpl)
and maintain application's own cache of compiled expressions.
I hope this helps.
- Dmitri wrote:
I have just joined the Commons list, and haven't seen any significant
messages addressing these subjects, so here goes:

I am working on a framework for my employer which is required to map
object graphs mirroring the database structure (data access layer) to
domain-specific (application service) object graphs. This will
essentially allow us to define Java object graph "views" on the data. 
While spiking on the problem I determined that JXPath may be a good fit
for mapping from the data access layer out to the business objects, and
the reverse driven by "breadcrumbs" (XPath statements) stored in the
business objects from the initial pull.

My remaining concerns are driven more by load and experience:
* Does JXPath work well in a multi-threaded environment (read: J2EE
application server)?
* How does it perform with medium sized object graphs (10-20 entities) in
a production environment attempting real-time graph traversals(we're using
a SunFire 15K, so we should have lots of horsepower)?

Kudos to the developers of JXPath, it's a great way to visualize and
interact with object graphs! Any help appreciated, thanks,

Scott Kidder

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message