Re: Is scm-maven thread safe?

[Emmanuel Venisse]

Personally, I think it would be better to use maven-scm, not because it's our project, but because 
it's open source and used by a large comunity with maven, so all commands are tested in different 
environment.

We have perhaps some bugs in Maven-SCM core or in providers, but when a bug is found in them, we try 
to fix it asap. So I think you can migrate to maven-scm, bormally all will be ok.

Emmanuel

Zsolt a écrit :
I gladly add new functionality or providers to the API but I would be
definitely not the right person to make such modifications in the core API.

Can somebody make some suggestions? I really have to make a decision:
maven-scm or not.

Our internal API supports cvs, svn, vss, pvcs and cm-synergy but maven-scm
has much more functionally thus I would love to replace our API but I need a
solution that can be used in a environment with lot of parallel users.

Zsolt


-----Original Message-----
From: Trygve Laugstøl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 11, 2006 2:23 PM
To: scm-users@maven.apache.org
Subject: RE: Is scm-maven thread safe?

On Tue, 2006-04-11 at 14:07, Zsolt wrote:

I have viewed a lot of maven-scm source code (but not maven core) and

find

the structure clean and I didn't see anything I would consider this API

as

NOT thread safe.

But it is very important to know from beginning what is NOT thread safe.

I

understand that also this API has probably bugs (like our software) but I
need more understanding the multi thread problems we can have or how they
can be prevented (I'm sure you understand, that sometime it is really

hard

to reproduce and fix a multi-thread related bug).

As I described below serialization of the request is not an option

because

one user can checkout and a second view resource history the same time.

Trygve, if I understand you correctly I should somehow assure that I

create

a new provider instance for each request.

Either that or ensure that all of the providers are thread safe.


I don't know how to do that but think it must be simple.

It boils down to either making the providers have this stanza in
components.xml:

<instatiation-strategy>per-lookup</instatiation-strategy>

and then have _each client return the instance_ back to the container so
that all requirements can be properly released.

The alternative is to make the providers thread safe too which might not be
too hard, and the API would be easier to use for the client.

I'm not entirely sure what the best way is but I would suggest that one
look into making the providers thread safe because that keeps the API
simple and easier to use for the clients. Easier to use usually means less
buggy client code which is good :) It *might* make the provider a bit
harder but I hope the cleaner/easier API should out weight the more complex
code.


If that is the only limitation, that is absolutely fine for me.

It's not a big requirement, but it might still be a hard one if there is an
issue. The core API is really simple and should indeed be pretty much
thread safe, but the providers might not be as they run processes etc which
they might have to keep track on over time etc.

--
Trygve