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
