Hi Werner,
But how to deal with the issue mentioned in 2. if one isn't able to
use
the work-around mentioned in 3.?
Help us making this cache thread-safe ....
It seems that we have no other choice than making
XMLClassDescriptorResolverImpl$DescriptorCacheImpl thread-safe.
The following approach comes to my mind:
1. Use ReentrantReadWriteLock to guard accesses to the
DescriptorCacheImpls internal list and maps
2. Get rid of this pesky DescriptorCacheImpl.getDescriptors()
IMHO it's poor API design to externally expose the caches internal
implementation (lists which are used as keys within a map) via an
iterator. Due to this API contract (the cache iterator is propagted
via XMLClassDescriptorResolverImpl.resolveAllByXMLName()) we have to
create an iterator from a clone of the caches internal list. Otherwise
we'll run into ConcurrentModificationExceptions if a new
XMLClassDescriptor is added to the list while the iterator is used.
Hopefully I will come up with a corresponding implementation next week.
But I have no idea on how to unit-test whether
XMLClassDescriptorResolverImpl is thread-safe or not.
Any hints?
Cheers,
Torsten
On 30.04.2009, at 09:17, Werner Guttmann wrote:
Hi Torsten,
Torsten Juergeleit wrote:
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)
+1.
2. XMLClassDescriptorResolverImpl is not thread-safe (due to the
non-thread-safe implementation of the inner class
DescriptorCacheImpl )
If I remember mails correctly, you are right.
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
Most definitely.
But how to deal with the issue mentioned in 2. if one isn't able to
use
the work-around mentioned in 3.?
Help us making this cache thread-safe ....
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?
Yes, see above. There's nothing that should prevent us from making the
descriptor cache thread-safe. All it takes is somebody's time and a
little bit of energy ....
Cheers
Torsten
---------------------------------------------------------------------
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
