followup on threads

[Benson Margulies <bi...@basistech.com>]

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.

 

 

 

RE: followup on threads

[Benson Margulies <bi...@basistech.com>]

Can I sell you a patch to introduce 1.5 generics in place of Object
(semi-serious)? This looks very interesting, thanks.

> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, August 31, 2007 12:05 PM
> To: cxf-user@incubator.apache.org
> Cc: Benson Margulies
> Subject: Re: followup on threads
> 
> 
> 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
> daniel.kulp@iona.com
> http://www.dankulp.com/blog

Re: followup on threads

[Daniel Kulp <dk...@apache.org>]

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
daniel.kulp@iona.com
http://www.dankulp.com/blog