jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel May <marcel....@consol.de>
Subject Re: Working with JCR in highly concurrent applications
Date Wed, 20 Sep 2006 13:34:50 GMT
I'm not sure, but Jackrabbit with a DB backend uses exactly one DB
connection (where all access going to the DB must be serialized over,
since JDBC connections can not be used concurrently) . So, if you're
using parallel access with lots of threads, all JCR access which
requires DB access gets more or less serialized.

I think the JCA adapter does pool Jackrabbit instances, each with an own
DB connection. Using the JCA Jackrabbit adapter should avoid this
problem ... maybe. Or use a FS backend instead of a DB....

Could this be an explanation for Alex's experience?
Can somebody confirm or comment this?


Alexandru Popescu wrote:
> Hi everybody!
> First of all I must say that I do not intend to create noise about
> this, but unfortunately it looks like I have reached a dead end.
> Hopefully there is something I am doing wrong, or that I am supposed
> to do differently. I haven't found any best practices or
> recommendations anywhere, so this is a try-and-fail process (and I am
> saying it is a "fail" because till now I haven't figured out the
> correct way to do it).
> Scenario: access a set of nodes (matching more or less complex
> filtering criteria) from a highly concurrent application.
> As you can see this is a pretty straight forward scenario.
> I have tried 2 different approaches and unfortunately both are
> degrading when used in this concurrent environment. And I am not
> talking about a few hundred concurrent threads: I have tested it with
> 50, respectively 100 concurrent threads.
> The common usage scenario is having a JCR Session per thread association.
> Usage scenario 1:  Query API.
> As posted in a previous email this is degrading very fast. See email:
> "possible performance problem (need a way to test it)" from Sept 19th.
> Usage scenario 2: Normal navigation API
> The second approach was to manually navigate the parent child nodes,
> read just a couple of properties in the first place so that I do
> manually the filtering, and only afterwards fetch the entire node
> properties.
> Once again, the performance is going down 2-3 order of magnitude (from
> hundreds of ms down to ten thousands (even hundred thousand) ms).
> I have profiled the 2nd test and at the first glance the most
> expensive operations are the following calls:
> ItemManager.createItemInstance
> ItemManager.retrieveItem
> These calls are always invoked from Node.getProperty,
> Node.hasProperty, etc., so I don't think I am doing something wrong.
> I am extremely worried about these results because I don't see a way
> to achieve my scenario without involving more advance techniques. I
> agree that if my application needs good performance these techniques
> will need to be used, but I find it very concerning the fact that
> performance is degrading so fast by its own.
> I would be happy to hear any comments, any suggestions, any pointers
> to what I am doing wrongly, that will lead me to a good solution.
> Many thanks in advance,
> ./alex
> -- 
> :Architect of InfoQ.com:
> .w( the_mindstorm )p.
> Co-founder of InfoQ.com

Marcel May
ConSol* Software GmbH
Tel: +49 89 45841-155

View raw message