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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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-03 17:08:17 CEST