Hi,
after reading through Castors XML best practices document, mailing
list entries and JIRA tickets regarding using Castor XML binding in
multi-threaded environments I came to the following conclusions:
1. For multi-threaded it's recommended to re-use a single instance of
XMLClassDescriptorResolver either indirectly via XMLContext or
directly via creating your own instance via
ClassDescriptorResolverFactory
.createClassDescriptorResolver(BindingType.XML)
2. XMLClassDescriptorResolverImpl is not thread-safe (due to the non-
thread-safe implementation of the inner class DescriptorCacheImpl )
3. To work-around the issue mentioned in 2. it's recommended to pre-
load all mapping and CDR files before starting to marshal / unmarshal
But how to deal with the issue mentioned in 2. if one isn't able to
use the work-around mentioned in 3.?
We're starting to use Castors XML binding (version 1.3) in a multi-
threaded environment with multiple WARs / EARs and >1000 Castor-
generated classes. Each of these WARs / EARs uses an isolated class
loader with its own instance of XMLClassDescriptorResolverImpl. Fully
pre-loading these instances of XMLClassDescriptorResolverImpl means
loading all Castor-generated classes and their descriptor classes the
same time in different class loaders.
This implies longer deployment / initialization time of the WARs /
EARs and increased JVM class loading memory (permanent generation).
Both are not viable options for us (deployment / startup time is
already 30 minutes and PermGen is already 512M).
Any suggestions?
Cheers
Torsten
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
