cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: followup on threads
Date Fri, 31 Aug 2007 17:52:11 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Yeah, it'd be very cool if we could write a SpringInvoker which does a
lookup every time an invocation happens. It may also be possible to do
it with AOP, although thats just a hunch and I don't have much of an
idea on specifics.<br>
<br>
Daniel Kulp wrote:
<blockquote cite="mid:200708311205.06095.dkulp@apache.org" type="cite">
  <pre wrap="">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:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->


  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Dan Diephouse
MuleSource
<a class="moz-txt-link-freetext" href="http://mulesource.com">http://mulesource.com</a>
| <a class="moz-txt-link-freetext" href="http://netzooid.com/blog">http://netzooid.com/blog</a></pre>
</body>
</html>

Mime
View raw message