Scott, 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
[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
