Hi, I have just returned from the W-JAX in Munich, and I have a very similar discussison on thread safety of the ClassDescriptorResolver [CDR] with a committer of the spring-ws project. Even though CDR might not be thread-sdafe as it is, I am sure we will (have to) have another look at this codebase, as imho it should be, indeed.
Regards Werner > -----Original Message----- > From: Michael Crozier [mailto:[EMAIL PROTECTED] > Sent: Freitag, 03. November 2006 21:40 > To: [email protected] > Subject: Re: [castor-user] ClassDescriptorResolver & thread safety > > > Ralf, > > I looked at the code and it all makes sense now. The > ClassCache and DescriptorCache objects are definitely not > thread safe. In practice they might be, provided the first > invocation was isolated and completely covered all the > classes & descriptors that will ever be seen. > > Most of that could be solved with some read and write locking > in the inner classes. I think I'll go with the thread-local > approach for now. > > Thanks for your help, > Michael > > > > Michael, > > > > XmlClassDescriptorReslover internally holds an instance of > > DescriptorCache which holds various instances of HashMaps and > > ArrayLists. If you only get objects from the cache which > consults the > > maps and lists I would not expect problems to use the CDR with > > multiple threads. Having said that I am not 100% sure about that. > > > > The problem may happen if you request a XML name (tag) or a > class that > > the CDR has not loaded before. At this cache miss it uses various > > strategies to search for a matching class or descriptor and > adds this > > to the cache. This modification of the cache is what I fear > may cause > > you headage. > > > > Having said that you should take a look at resolve() and > > resolveXml() methods of XmlClassDescriptorResolver yourself > to verify > > my above statement. It should not be to difficult to understand the > > basics that are happening there. > > > > Regards > > Ralf > > > > Michael Crozier schrieb: > > > Tom & Ralf, > > > > > > Thanks for the answers. > > > > > > One additional question: Is ClassDescriptorResolver not > thread safe > > > during the use of the Unmarshaller and Marshaller > objects, or just > > > during the construction? > > > > > > For example, if I locked the ClassDescriptorResolver during the > > > invocation of marshaller.setResolver(), would that provide thread > > > safety? > > > > > > Or is the opposite true, that I need a distinct > > > ClassDescriptorResolver for each Marshaller and > Unmarshaller object > > > that is being used concurrently? > > > > > > If the latter is true, then I will likely maintain thread-local > > > ClassDescriptorResolver objects. > > > > > > Thanks again, > > > > > > Michael > > > > > >> Hi Tom, > > >> > > >> you are right that the XML best practice document should > point out > > >> that ClassDescriptorResolver is not thread safe. Sorry for that > > >> confusion. I'll take care to update docs or make > > >> ClassDescriptorResolver thread safe for next release. > > >> > > >> Regards > > >> Ralf > > >> > > >> Carey, Tom schrieb: > > >>> This link below talks about reusing ClassDescriptorResolvers to > > >>> achieve best performance. Is this link suggesting that it is > > >>> thread-safe? > > >>> If so, maybe > > >>> this page should be updated. > > >>> > > >>> http://www.castor.org/xml-best-practice.html > > >>> > > >>> Tom > > >>> > > >>> -----Original Message----- > > >>> From: Ralf Joachim [mailto:[EMAIL PROTECTED] > > >>> Sent: Friday, November 03, 2006 2:50 AM > > >>> To: [email protected] > > >>> Subject: Re: [castor-user] ClassDescriptorResolver & > thread safety > > >>> > > >>> Hello Michael, > > >>> > > >>> as far as I can see when looking at the source of > > >>> XMLClassDescriptorResolver it isn't thread safe by > design. While I > > >>> think there should be no problem if all ClassDescriptor's are > > >>> loaded before starting to un-/marshal, I'd suggest to > go safe and > > >>> use them in a thread safe way. E.g. one CDR per thread or by > > >>> implementing a CDR pool. > > >>> > > >>> Regards > > >>> Ralf > > >>> > > >>> Michael Crozier schrieb: > > >>>> Hello, > > >>>> > > >>>> As outlined in the best practices document, I'm using > > >>>> ClassDescriptorResolver to load and cache mappings. I > understand > > >>>> that Marshaller and Unmarshaller objects are not > thread safe, but > > >>>> ClassDescriptorResolver has no mention of thread-safety. I am > > >>>> using this mechanism to load mappings from String objects and > > >>>> well as from > > >>> > > >>> Files. > > >>> > > >>>> Is it thread-safe to share a single ClassDescriptorResolver > > >>>> instance between many threads, in which new > marshalling objects > > >>>> are created > > >>> > > >>> per-invocation? > > >>> > > >>>> Many thanks, > > >>>> > > >>>> Michael > > >>>> > > >>>> > > >>>> -------------------------------------------------------------- > > >>>>------- To unsubscribe from this list please visit: > > >>>> > > >>>> http://xircles.codehaus.org/manage_email > > >>> > > >>> --------------------------------------------------------------- > > >>>------ To unsubscribe from this list please visit: > > >>> > > >>> http://xircles.codehaus.org/manage_email > > >>> > > >>> --------------------------------------------------------------- > > >>>------ To unsubscribe from this list please visit: > > >>> > > >>> http://xircles.codehaus.org/manage_email > > >> > > >> -- > > >> > > >> Syscon Ingenieurbüro für > > >> Meß- und Datentechnik GmbH > > >> Ralf Joachim > > >> Raiffeisenstraße 11 > > >> D-72127 Kusterdingen > > >> Germany > > >> > > >> Tel. +49 7071 3690 52 > > >> Mobil: +49 173 9630135 > > >> Fax +49 7071 3690 98 > > >> > > >> Email: [EMAIL PROTECTED] > > >> Web: www.syscon-informatics.de > > >> > > >> ---------------------------------------------------------------- > > >>----- To unsubscribe from this list please visit: > > >> > > >> http://xircles.codehaus.org/manage_email > > > > > > ----------------------------------------------------------------- > > >------- > > > > > > ----------------------------------------------------------------- > > >---- To unsubscribe from this list please visit: > > > > > > http://xircles.codehaus.org/manage_email > > -- > > Conducive Technology Corporation > Taking Worldwide Flight information > to the next level. > > http://www.conducivetech.com > http://www.pathfinder-web.com > http://www.flightstats.com > > Michael Crozier [EMAIL PROTECTED] > > Voice: 503.445.4233 > Fax: 503.274.0939 > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
