Hello Mark,
> There are only two client implementations and they are both threadsafe
> and I do not understand the username/password issue you describe.
I have a correction on this statement - SVNKit's SVNClient
implementation (SVNClientImpl) is not thread safe, i.e. it is expected
that instance of SVNClientImpl is not used from different threads at the
same time.
It could be used this way when wrapped into SVNClientSynchronized
though, but I think other issues may arise, including those with
credentials.
Regarding credentials, there is one more thing I could share about
SVNKit's SVNClient implementation - when works within Eclipse SVNKit
uses multi-layer credentials cache and looks for credentials in the
following order:
0. credentials specified with username/password methods.
1. credentials stored in _runtime credentials cache_.
2. credentials stored in keyring file, i.e. persistent credentials cache.
3. credentials fetched from UserNamePassword prompt.
Credentials that are accepted for certain realm are then always stored
in runtime credentials cache, even when user decided not to save them
(to avoid prompting credentials during the same session for each
operation). By default runtime credentials cache is synchronized and
shared between all SVNClientImpl instances.
SVNClientImpl instance allows to set custom shared runtime storage with
SVNClientImpl.setRuntimeCredentialsStorage(...) method or override this
for certain SVNClientImpl instance with
SVNClientImpl.setClientCredentialsStorage(...) call.
I'm not sure whether this information is relevant to the topic (didn't
yet read it all), but this is where SVNKit implementation differs from
the JavaHL one.
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
Mark Phippard wrote:
> On Tue, Jun 3, 2008 at 10:37 AM, Thomas Hallgren <thomas_at_tada.se> wrote:
>
>> The adapter is stateful (holds username/password info) and it isn't always
>> synchronized. So in order to do something in parallel, you'll need more then
>> one instance. The way it used to work, I could create new instances as I
>> went along and dispose them when I was done. Not so now. There's only one
>> instance and it delivers incorrect content, considers my files to be
>> directories, or logs in using incorrect username/password if I try to use it
>> from multiple threads.
>
> Subclipse stopped containing usernames and passwords before the 1.0
> release. The code still exists but the values would be null if using
> our UI. So the adapter under "normal" Subclipse usage does not
> contain any username or passwords, it simply contains callback
> functions that the Subversion API can choose to use if and when it
> needs to ask for credentials.
>
>> Specifically, it is impossible to perform paralell task on an
>> ISVNClientAdapter delivered by the SVNClientManager.createSVNClient() or
>> the ISVNRepositoryLocation.getSVNClient() method. I'm confined to use those
>> methods since there's no other way of getting a client adapter properly
>> initialized according to the preferences, usernames, and passwords that
>> Subclipse maintains through preferences and repository locations.
>
> I am not clear why it is impossible.
>
>>> We made this change to potentially boost performance slightly, by not
>>> constantly constructing new adapters, and more importantly because we
>>> were not using the JavaHL API properly in that we were never calling
>>> the dispose() method. Doing so would essentially be impossible to add
>>> and get tight. JavaHL itself is threadsafe and it seemed like a lot
>>> better way to work with it.
>>>
>> The fact that JavaHL is capable of multi-threading is of little importance
>> to me. I want to provide a stable implementation on top regardless of client
>> implementation. The choice is up to the user. But even if all client
>> implementations were multi-thread safe, you still assign username/password
>> to the client instance. So thread-safe or not, it cannot be used from
>> multiple threads unless those threads are using the same username/password.
>
> There are only two client implementations and they are both threadsafe
> and I do not understand the username/password issue you describe.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-06-09 17:49:54 CEST