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. I don't know how to do that but think it must be simple. If that is the only limitation, that is absolutely fine for me. Zsolt >-----Original Message----- >From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] >Sent: Tuesday, April 11, 2006 1:33 PM >To: scm-users@maven.apache.org >Subject: RE: Is scm-maven thread safe? > >On Tue, 2006-04-11 at 12:10, Zsolt wrote: >> Trygve, >> >> Are you sure? In this case maven-scm is not an option for us. After >spending >> some days on maven-scm and implementing ScmProvider.listTask I really >like >> this API and even plan to add CM-Synergy support, but we are going to use >> this API from servlets, thus it must be thread safe. You might know >> javaforge.com that is based on our software with hundreds of projects and >> thousands of users. Serializing the request is just not acceptable for us >> (for the users) because it is very probably that more than one user want >to >> browse repositories. > >If something isn't thread safe just means that you'll have to use more >instances of the thing in question. > >But, if this is something that's really important it wouldn't be hard to >ensure (and keep) the core thread safe, and if the providers are used on a >per lookup-basis you should be home safe. For all I know the core is >practically thread safe already. > >I think the solution I've outlined above is the easiest solution (keeping >the core thread safe, and just instantiate the providers per usage. The >biggest issue with this is that the user of the provider will have to >return/dispose the instance once it's done with it. > >-- >Trygve
