You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Hendrickson, Jacob" <ja...@etrade.com> on 2004/11/09 22:21:19 UTC

Using axis client stubs from a webapp

I'm using client stubs generated by wsdl2java in a web application, and I'm curious about the best way to instantiate the stub objects.

I use the stub objects to call methods on a SOAP service on several different pages, so that the SOAP methods get called on per-request basis.

Right now I'm using the approach of creating a new stub object per-session, so all the requests for a given session share the same stub object.

But I'm thinking of using a singleton approach to create the stub, rather than a new one for each user session. 

Is there any reason not to share a stub instance like this? Would it have any performance implications? Would multiple page requests be able to call the stub's methods concurrently without blocking or interfering with each other? 

Looking at the generated code for the stub class, I see the class has 4 private instance variables, all of type java.util.Vector. Because of this, it seems that sharing one stub instance across multiple threads would cause problems. 

How have other people solved this problem? I'd like to instantiate as few stubs as possible, while maintaining thread safety and not hindering performance/scalability.

Thanks

JH

--
--

Jacob Hendrickson
Software Engineer
E*Trade Financial
jacob.hendrickson@etrade.com


This e-mail is the property of E*TRADE FINANCIAL Corporation. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please immediately notify the sender by e-mail at jacob.hendrickson@etrade.com and telephone at 646-521-4781. Please delete and destroy any copies of this e-mail.