Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of ianboston@googlemail.com
 designates 209.85.220.162 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=sender:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=e4PSJYJTfu6lZXej2Bk/+URd+hZDGEXvuSjkgVJZ8Y/X/QAveqn4MobSzx38nhjy9W
         8nQUClLIPjHAKa+Z2+cFVzuE6pI1HOw+EIDQaL+fv92mGuz+hvOukjb00knilnxrXpm4
         +a+cYGxjaHTiqWlVL77pws0e0kNVok4Hm12TQ=
Sender: Ian Boston <ianboston@googlemail.com>
Message-Id: <3041FF65-6004-47CC-82A8-68DA1A6E35FB@tfd.co.uk>
From: Ian Boston <ieb@tfd.co.uk>
To: users@jackrabbit.apache.org
In-Reply-To: <23277508.post@talk.nabble.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Database Connections and Performance
Date: Tue, 28 Apr 2009 15:04:23 +0100
References: <23277508.post@talk.nabble.com>

Jackrabbit has its own multi threaded state management. Everything is  
focused on serving information from memory and not performing a query  
against the database. Only when a session needs to get something that  
isn't in one of the shared caches will you see queries hitting the  
database.

On the persistent manager connection you will probably see a stream of  
insert and update statements (perhaps with some selects), but you will  
not see the same volume of selects that you saw with a normal RDBMS  
application since most activity will be services from shared cache.

The one connection where you will see activity is the Journal  
connection that last time I looked in 1.4 needs to serialize the  
journal creation so that all nodes can perform replays in step. Hence  
there will be a select to generate a new sequence, and an insert to  
save the sequence.

The side effect of all of this is that jackrabbit can support a higher  
level of concurrency in the web application layer than you would be  
able to support if each request thread required a database connection.  
The JCR sessions are lighter weight than JDBC sessions simply because  
they don't require a network connection. (although pooling removes  
that need)

However, if you are seeing excessive SQL traffic, and would like to  
reduce it, using an XATransaction manager (eg from JTA) will batch up  
the SQL traffic to when the transaction is committed and the transient  
state is persisted from the session state.

To make jackrabbit use one connection per thread, you would have to  
refactor quite a lot of code above the persistence manager. I suspect  
writing a new Jackrabbit SPI implementation would do this, but thats  
certainly not trivial.

HTH
Ian

On 28 Apr 2009, at 14:47, majohnst wrote:

>
> I am trying to better understand how Jackrabbit performs queries on  
> a mysql
> database filestore/persistance manager. I understand that when  
> Jackrabbit
> starts, it creates several persistent connections to the database.  
> One for
> the datastore, one for the workspace, one for the journal (for  
> clustering),
> etc. Jackrabbit cannot use connection pools, so there is no need to  
> setup a
> database connection pool.
>
> My question is, when I query jackrabbit (or other jcr operation that  
> needs
> to read from the mysql database), is there really only one  
> connection to my
> mysql database? Do all queries go into a queue and only one query is
> executed at a time? So there is no idea of simultaneous querying with
> jackrabbit? Is there any way to increase the number of queries  
> jackrabbit
> can do at one time?
>
> Our application has a very high number of concurrent users and we  
> are seeing
> a slow down because jackrabbit cannot execute the queries fast  
> enough. I am
> hoping that there is a way I can increase the number of queries that
> jackrabbit can execute at one time.
> -- 
> View this message in context: http://www.nabble.com/Database-Connections-and-Performance-tp23277508p23277508.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>