axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <>
Subject RE: Generated stubs are not thread safe
Date Thu, 10 Jan 2002 15:06:37 GMT

Actually, I was thinking about this.

The thread safety problem only occurs if a client gets the Stub object, then hands it around
to different threads, which call web service operations at the same time.   Right?

It doesn't seem to me like this is a really good way to use stubs at all, so I would say making
the operations synchronized wouldn't be such as bad thing.  It would be pretty easy for any
client app who wanted to call operations on the same service to just get a stub for each thread
that needed to call.

We can always revisit in later revisions if it really is a problem.

+1 to synchronizing the stub methods.

Tom Jordahl

-----Original Message-----
From: Russell Butek []
Sent: Wednesday, January 09, 2002 5:44 PM
Subject: RE: Generated stubs are not thread safe


We CAN'T create a new Call object on every method call.  Not unless we want
to throw away setMaintainSession.  So the only solution I see is to
synchronize each stub method (or part thereof).  Anybody have any better

Russell Butek

Russell Butek/Austin/IBM@IBMUS on 01/09/2002 08:24:16 AM

Please respond to

Subject:  RE: Generated stubs are not thread safe

Glyn, that complicates the programming model and we'd have to get JAX-RPC
to go along with it.

I don't particularly like how the preamble to every method call now looks,
but since a new Call object for every method is the way folks want to go,
and it's probably still cheaper than synchronizing each method, that's what
I'll do.

Russell Butek

Glyn Normington/UK/IBM@IBMGB on 01/08/2002 09:42:22 AM

Please respond to

Subject:  RE: Generated stubs are not thread safe


>Or is there a reasonable way to make the Call object itself thread safe?

Have you considered a two-stage Call object that implements Cloneable?

After construction it would allow itself to be "configured", i.e. set up
with contents that would apply to all thread usages, and then it would
require clone() to be used each time the object is to be invoke()d and the
"invoke" method issued against the clone.


View raw message