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:[EMAIL PROTECTED] > Sent: Friday, August 31, 2007 12:05 PM > To: [email protected] > 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 > [EMAIL PROTECTED] > http://www.dankulp.com/blog
