On Fri, Feb 18, 2011 at 1:30 PM, Simon Nash <n...@apache.org> wrote: > Simon Laws wrote: >> >> On Thu, Feb 17, 2011 at 6:39 PM, Scott Kurz <scottk...@gmail.com> wrote: >>> >>> Simon, >>> >>> The cache allows us to reuse the JAXBContext across repeated service >>> invocations. The fact that you don't hit the cache again after a >>> restart shouldn't be surprising, as we'd typically use a different >>> Classloader with different Class objects, right? >>> >>> I haven't fully digested the JAXB issue in the CXF JIRA, so I'll just >>> leave it at that.....but thought I could help a bit by mentioning >>> that. >>> >>> Scott >>> >> >> Raymond/Scott, thanks for the responses. It's becoming a little >> clearer. So the cache is then targeted at improving performance across >> multiple calls through an interface and has no use across node >> restarts (because we rebuild the classes). In that case I would >> suggest clearing the cache at node stop however this probably would >> make matters worse in the multiple nodes in the same VM scenario >> because the cache is ultimately accessed via a static >> JAXBContextCache. >> >> Regards >> >> Simon >> > Perhaps a node that is stopping could discover whether there are any > other nodes still running in the same JVM and not clear the cache > in that case. > > This could be done by nodes registering with the static cache when > they are started and deregistering when they are stopped. > > Simon >
Or maybe we should have a cache per node (maybe that could be done with the approach you're suggesting). No sure why the JAXBContextCache is static. It's maybe hard to get a node oriented object into the databinding. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
