Hi, Mads Henrik Stavang wrote: > Thanks, it looks like it worked. One last question: Can I call > createUnmarshaller() without synchronizing the call, or is it not > thread-safe? Calling XMLContext().createUnmarshaller definitely is thread-safe. In other words, call this method from your threads at will.
Werner > > Regards Mads > > -----Ursprüngliche Nachricht----- Von: Werner Guttmann > [mailto:wgut...@codehaus.org] Gesendet: Mittwoch, 6. Mai 2009 21:15 > An: dev@castor.codehaus.org Betreff: Re: [castor-dev] > Unmarshaller.setMapping is not thread safe when using the same > mapping object > > Hi, > > not really, as the Mapping object is not thread-safe by definition. > Personally, I'd encourage you to start using the new XMLContext > class. The way to go about this problem is to .. > > a) create a Mapping instance b) load your mappings through > Mapping.loadMapping() c) Create a XMLContext() instance, and set the > mapping there d) Spawn of Unmarshaller instances from this > XMLContext() class using the createUnmarshaller() method. > > I hope this helps. > > Cheers Werner > > Mads Henrik Stavang wrote: >> Hello, >> >> >> >> I have just updated my castor version from 1.0 to 1.3, and I >> encountered a problem with the Unmarshaller when using the same >> mapping object in different threads. >> >> >> >> In my current application, I noticed this as one of my objects was >> only partially unmarshalled (it was missing some of the attributes >> in the xml-file). This object was unmarshalled at the same time as >> another object, both with separate Unmarshalle-objects, but using >> the same Mapping-object. >> >> >> >> First I tried to reproduce this behavior in a cleaner environment, >> without luck. I guess it is a timing issue, which I cannot >> reproduce under my artificial test-environment. Then I tried >> reproduce it with breakpoints in my debugger and I managed to >> create a different bug, with an exception: >> >> >> >> org.exolab.castor.xml.MarshalException: Stream closed >> >> at >> org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:757) >> >> >> at >> org.castor.mapping.MappingUnmarshaller.loadMappingInternal(MappingUnmars >> haller.java:247) >> >> at >> org.castor.mapping.MappingUnmarshaller.getMappingLoader(MappingUnmarshal >> ler.java:155) >> >> at >> org.castor.mapping.MappingUnmarshaller.getMappingLoader(MappingUnmarshal >> ler.java:130) >> >> at >> org.exolab.castor.xml.Unmarshaller.setMapping(Unmarshaller.java:525) >> >> >> at test.DBConnectionCfg.unmarshal(DBConnectionCfg.java:111) >> >> at test.DBConnectionCfg.unmarshal(DBConnectionCfg.java:121) >> >> at test.Test$2.run(Test.java:41) >> >> at java.lang.Thread.run(Thread.java:619) >> >> >> >> The critical region is: >> >> >> >> private void loadMappingInternal(final Mapping mapping, final >> DTDResolver resolver, >> >> final InputSource source) >> >> throws MappingException { >> >> // Clear all the cached resolvers, so they can be reconstructed a >> >> // second time based on the new mappings loaded >> >> _registry.clear(); >> >> >> >> Object id = source.getSystemId(); >> >> if (id == null) { id = source.getByteStream(); } >> >> if (id != null) { >> >> //check that the mapping has already been processed >> >> if (mapping.processed(id)) { return; } >> >> // *** Critical, error is produced if both >> >> // *** threads reach this point at the same time >> >> >> >> //mark the mapping as being processed >> >> mapping.markAsProcessed(id); >> >> } >> >> >> >> >> >> This is not the same issue which I discovered in my application, >> and I could not reproduce this error without the debugger, but they >> are somehow related. When I put a synchronized-block over >> Unmarshaller.setMapping(), my original issue disappeared. I tried >> to find the cause of my issue, but I this is the first time I have >> looked into the source code, and I really don't know where to look. >> >> >> >> >> So, should I report this as a bug? >> >> >> >> Best regards, >> >> Mads Stavang >> >> > > --------------------------------------------------------------------- > 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
