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
