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
