[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Speed up client by re-using RA session connections

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Wed, 14 Sep 2011 17:59:20 +0100

Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Sep 14, 2011 at 16:07:19 +0100:
> > Enable libsvn_client APIs to re-use a previous RA session instead of always
> > opening a new connection.
> >
> > Basically:
> >
> > - Declare an opaque "RA session cache" object in the public API. It holds
> > one open RA session per repository, for any number of repositories.
> Why per repository?

Because the caller of a libsvn_client API generally provides a
"path_or_url" without knowing which repository it refers to. If the
client is calling e.g. "update a/", "update b/", "update c/", it doesn't
know in advance whether those paths refer to different repositories.
Suppose only "a" and "c" are in the same repo; the client can't pass
just a single cached session if we want to re-use the "a" session for

> What about a client that runs 'svn update' on several
> wc's of the same URL concurrently?

I haven't attempted to support concurrent calls. The cache is for
sequential use only (one user of the cache at a time). If a client is
doing parallel updates and want to use this kind of cache it must have a
separate cache per thread. I think.

> > - Implement a private API for libsvn_client functions to use instead of
> > simply opening a new session. It re-uses a session from the cache, if
> > present, or opens a new connection if necessary.
> As far as I can see, the "get a session from the cache" code assumes
> that the cache is used by a single thread. (Consider what happens if
> one thread retrieves or uses a cached session while another retrieves
> the same session from the cache.) Will the cache be thread-safe?

See above.

- Julian
Received on 2011-09-14 19:00:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.