Benson,
The jaxws:server/endpoint elements in the spring config do allow for a
custom "invoker" bean. (implements our Invoker interface) You could
write a custom invoker that pools instances, assigns them per thread,
etc... On trunk, I just added a method to our base invoker class that we
use (AbstractInvoker) that could make it easier. For jaxws, you could
subclass the JAXWSMethodInvoker and override the two methods:
public abstract Object getServiceObject(final Exchange context);
public void releaseServiceObject(final Exchange context, Object obj);
to do whatever book keeping you need.
Dan
On Thursday 30 August 2007, Benson Margulies wrote:
> This is perhaps really a spring question, but the readers of this list
> must have hit this before.
>
>
>
> SEI classes are reentrant.
>
>
>
> CXF services are frequently deployed in Spring and constructed with
> Spring-managed beans.
>
>
>
> Spring doesn't seem to offer much in the multithreading department.
>
>
>
> To be a bit more concrete, consider an SEI class that is handed a set
> of supporting beans via IoC. If those objects are reentrant
> themselves, well, life is good. What if they are not?
>
>
>
> The SEI can synchronize and single-thread their use. Effective, but
> not popular when trying to achieve high usage of multiple processors.
>
>
>
> Or, we could abandon IoC here, and let the SEI make Spring calls to
> obtain new instances of the beans (declaring them appropriately) and
> stash them in thread local storage.
>
>
>
> This would work best if CXF was keeping some sort of pool of SEI's
> around to go with the threads, and I haven't researched that yet.
>
>
>
> It seems a shame to have to decorate the SEI class with a bunch of
> spring interactions. I suppose that a trick could be had: an
> intermediate bean that served as a factory for the non-thread-safe
> objects, and which hid the interactions with the IoC container inside
> of itself.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
