> Our first design was simple - when you need to make a call, just create > a new one. However creation of a Call is not so light - further it will > also require to create additional DocumentBuilder, and > SOAPMappingRegistry, both not so light.
I agree with this point. Some time ago, we switched to reusing the Call object (we also use a static shared SOAPMappingRegistry). I don't recall the specific performance improvement, but I think it was on the order of 1-2 ms saved. > So we cached a Call, one per thread, and also cached a > SOAPMappingRegistry, one per all Calls. SOAPMappingRegistry created in We ran into a couple stumbling blocks with this one. First, to do a Call per thread, the natural implementation is to use ThreadLocal. Alas, our stuff gets used inside some other folks EJBs, and you can't use ThreadLocal in that case (EJB rules of engagement). The next attack was to use a static Call object inside one of our objects which the caller allocated. Unfortunately for us, the caller found it inconvenient to avoid sharing our object, so we had to make access to the use of the Call object thread-safe. As Pavel noted, that's tricky because you have multiple method calls on Call object to actually accomplish a SOAP request/response. You can synchronize all that, but then you end up serializing your throughput. Ultimately (heh, at least "ultimately so far"), we used the static Call object but made a way to mark it "in use". In case it was in use, we allocated another one and then threw it away when done. So, most of the time the static Call object gets reused in a multithreaded environment, but when there does happen to be a collision we don't block the other threads. We think of this as having a sort of a connection pool that just happens to have a single connection available. :-) -- To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
