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