axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <bu...@us.ibm.com>
Subject RE: Generated stubs are not thread safe
Date Tue, 08 Jan 2002 14:48:22 GMT
It might make sense for this stuff to be in the service, and for the Call
ctor to take all that info, but since it can change on a per-Call basis as
well, we'll still need to put this logic into every method (perhaps wrapped
by "if (anything changed) ...").

Or is there a reasonable way to make the Call object itself thread safe?
Offhand, I can't think of any.

Russell Butek
butek@us.ibm.com


Glen Daniels <gdaniels@macromedia.com> on 01/07/2002 04:01:53 PM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: Generated stubs are not thread safe




Followup : it certainly is possible to want to set this stuff on a per-Call
basis as well (i.e. one method on a service might require headers, and
another might not), so you'd need to be careful about where you did what -
you wouldn't necessarily want everything at the shared service layer.  But
this is good stuff to figure out.

> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Sent: Monday, January 07, 2002 4:58 PM
> To: 'axis-dev@xml.apache.org'
> Subject: RE: Generated stubs are not thread safe
>
>
>
> This is exactly the kind of thing I was talking about moving
> up into the Service, since the Service maps one-to-one with
> the engine, and the engine is where the
> serializers/deserializers are actually registered.  We
> definitely don't want to be repeating this code all over the place.
>
> --G
>
> > -----Original Message-----
> > From: Russell Butek [mailto:butek@us.ibm.com]
> > Sent: Monday, January 07, 2002 4:23 PM
> > To: axis-dev@xml.apache.org
> > Subject: RE: Generated stubs are not thread safe
> >
> >
> > One note of warning about creating a new call object in each
> > method.  Right
> > now the constructor instantiates the Call object and
> > registers serializers
> > and deserializers.  And there are a number of methods that
> > delegate to the
> > Call object:  _getProperty, _setProperty, _getTargetEndpoint,
> > _setTargetEndpoint, setMaintainSession.  These values will
> have to be
> > cached and delegated to each call object in each method call.
> >  In other
> > words, each stub method method will have to do the following
> > before doing
> > what it does now:
> >
> >             Call call = (org.apache.axis.client.Call)
> > service.createCall();
> >             for (each cached serializer) { // the serializers
> > are cached in
> > the ctor
> >                 call.addSerializer(cls, qn, serializer);
> >             }
> >             for (each cached deserializer) { // the
> deserializers are
> > cached in the ctor
> >                 call.addDeserializerFactory(qn, cls, serializer);
> >             }
> >             for (each cached property) { // the properties
> > are cached in
> > _setProperty
> >                 call.setProperty(key, value);
> >             }
> >
> > call.setProperty(org.apache.axis.transport.http.HTTPTransport.URL,
> > cachedAddress.toString()); // for the target endpoint
> >             call.setMaintainSession(cachedMaintainSession);
> >
> > Do y'all still think this is a good thing to do?
> >
> > Russell Butek
> > butek@us.ibm.com
> >
> >
> > Sam Ruby/Raleigh/IBM@IBMUS on 01/07/2002 02:23:28 PM
> >
> > Please respond to axis-dev@xml.apache.org
> >
> > To:   axis-dev@xml.apache.org
> > cc:
> > Subject:  RE: Generated stubs are not thread safe
> >
> >
> >
> > Tom Jordahl wrote:
> > >
> > > +1 to create a new call object in each method.
> > > I assume creating them is not particularly expensive...
> >
> > Dug made a change recently to make Call objects fairly inexpensive.
> > Service objects remain expensive (this causes the
> > initialization of the
> > engine, potentially including the parsing of wsdd).
> >
> > - Sam Ruby
> >
> >
> >
>



Mime
View raw message