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

Re: svn commit: r1657782 - /subversion/branches/reuse-ra-session/BRANCH-README

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 06 Feb 2015 14:38:23 +0100

On 06.02.2015 13:55, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: brane_at_apache.org [mailto:brane_at_apache.org]
>> Sent: vrijdag 6 februari 2015 12:10
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1657782 - /subversion/branches/reuse-ra-
>> session/BRANCH-README
>>
>> Author: brane
>> Date: Fri Feb 6 11:09:54 2015
>> New Revision: 1657782
>>
>> URL: http://svn.apache.org/r1657782
>> Log:
>> On the reuse-ra-session branch: Documentation change: Instead of expecting
>> clients to manage the lifetime of idle sessions, expect that the RA cache
>> implementation will take care of that itself and hide the complexity
>> from the API.
>>
>> * BRANCH-README:
>> Remove todo item about svn_client_close_all_sessions.
>> Add todo item about idle session expiry.
> How do we expire idle sessions if a client only uses Subversion api's once a day?

Why should such a client keep the context around for a whole day?

> I don't think we want to rely on timers or threads.

See r1657802.

> Before this is merged back I would really like some supported option to just close all sessions (perhaps including those to the working copy databases), without destroying the client context.
>
> The context also caches credentials, etc.
>
>
> In shared process environments such as Eclipse and Visual Studio where libsvn_client is indirectly used, we can't just always hold on to expensive/limited resources.

Context creation is relatively cheap, even considering credentials
caches and so on. No-one should have to keep a context around for hours,
let alone days.

Any implementation of close_all_sessions will have one of two drawbacks:

  * it will either close only the idle sessions, or
  * by closing all sessions, it will expose the user to nasty bugs
    related to keeping session references outside the context.

Clearing the context pool, on the other hand, avoids all these issues,
and avoids further clutter in the public API.

Until we actually see a client that treats contexts as heavy-weight
objects that require careful management, as opposed to large-yet-simple
objects that can be re-created any time they're needed, we certainly
don't need such explicit session management. And even then I'll argue
that said client is misusing our API.

-- Brane
Received on 2015-02-06 14:39:40 CET

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.