You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by sc...@urlgrey.net on 2004/10/22 23:02:54 UTC
JXPath: Thread-Safe Behavior and Real-Time Applications
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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [JXPath] Compiled Expressions Cache Impl? (was: Re: JXPath: Thread-Safe Behavior and Real-Time Applications)
Posted by Dmitri Plotnikov <dm...@apache.org>.
Manos,
I recommend that you maintain cache outside JXPath. Use
JXPathContext.compile(xpath) to get a compiled expression and store it in
your own cache. I think this would be better than exposing the internals of
JXPath cache.
Good luck,
- Dmitri
----- Original Message -----
From: "Emmanouil Batsis" <Em...@eurodyn.com>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Tuesday, November 02, 2004 6:28 AM
Subject: [JXPath] Compiled Expressions Cache Impl? (was: Re: JXPath:
Thread-Safe Behavior and Real-Time Applications)
>
> Hi,
>
> Dmitri Plotnikov wrote:
>
>>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.
>>
>
> Thanks for the above, *very* informative as I also have thread-safety
> requirements on XML trees of unknown structure and size. I was thinking of
> implementing a statistics-and-total-cache-size-based mechanism to figure
> out frequently used expressions, then store those, but I'm not sure how
> accessible the JXPath cache is (can i selectively store and remove
> compiled expressions?), or how easily another cache can be implemented and
> what that should be like... any suggestions?
>
> Many thanks,
>
> Manos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[JXPath] Compiled Expressions Cache Impl? (was: Re: JXPath: Thread-Safe
Behavior and Real-Time Applications)
Posted by Emmanouil Batsis <Em...@eurodyn.com>.
Hi,
Dmitri Plotnikov wrote:
>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.
>
Thanks for the above, *very* informative as I also have thread-safety
requirements on XML trees of unknown structure and size. I was thinking
of implementing a statistics-and-total-cache-size-based mechanism to
figure out frequently used expressions, then store those, but I'm not
sure how accessible the JXPath cache is (can i selectively store and
remove compiled expressions?), or how easily another cache can be
implemented and what that should be like... any suggestions?
Many thanks,
Manos
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: JXPath: Thread-Safe Behavior and Real-Time Applications
Posted by Dmitri Plotnikov <dm...@apache.org>.
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
scott@urlgrey.net 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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org