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

Re: Multiple Concurrent Connections?

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-07-20 01:46:27 CEST

[cc'ing the dev list, please keep replies on it]

Tim Coulter wrote:
> Bliar,
>
>> In my multithreaded Python Ice Subversion server, I have a pool of
>> svn_fs_t's that are checked out and checked back in per RPC request. If
>> the pool is empty, I just create a new svn_fs_t.
>
> I'm trying to get a sense of what you meant by pool. Did you mean an
> actual Subversion pool (whatever class that equates to; something like
> apr_pool_?) or did you simply mean "a set" of them, such as an array
> within the main process?

No, more like a database connection pool, where you borrow a connection for a
while then return it when you are done with it. If the pool is empty, I just
create a new svn_fs_t.

> Also, are your svn_fs_t's linked with the specific paths they associate
> to, so as not to check out the same one twice? For instance, when an RPC
> wants to check out an svn_fs_t for path "/a_path", and the svn_fs_t
> checked out for "/a_path" is in use, will the thread for that RPC wait
> until the "/a_path" svn_fs_t is checked back in? If so, do directories
> work the same way (i.e, will "/some/path" block "/some/other_path"
> because they have the same parent directory)?

No, the svn_fs_t's aren't linked to the path inside the repository.

You can have multiple svn_fs_t's all operate on the same path in the same
repository, so there's no need to block. Just create a new svn_fs_t if you
don't have any available. They don't keep open file descriptors around, so they
are cheap.

My server allows for multiple Subversion repositories, so all RPC calls take a
repository name as one of their arguments, then the name is used to look in the
svn_fs_t pool to see if there is one available for that repository, and return a
new or old one.

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 20 01:45:39 2007

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.