Could you describe exactly what's happening when you have problems? I'm assuming it's
a deadlock situation, but I'm not sure I understand it - and in fact I think I see a
bug in the current code. The lock is on the Session object (i.e. the AxisHttpSession
for HTTP). It looks to me like there will be one of those per request
(AxisServlet:693)... so the locks aren't actually doing what I want them to, are they?
In other words:
1. Thread 1 accepts request, wraps HTTPSession[A] with AxisSession[X]
2. Thread 2 accepts request, wraps HTTPSession[A] with AxisSession[Y]
Locking on the objects at X and Y will produce two different locks, and won't prevent
the other thread from modifying the HTTPSession contents beneath the wrapper.
In fact, does the servlet API even mandate that you'll get exactly the same
HTTPSession object for different requests across different threads? Do we have to
lock on the session ID instead?
I can see this being a problem at present with the application scope, because that
really IS the same object each time. So is that what you're experiencing?
--Glen
P.S. Your solution will almost work, although you shouldn't lock a String, just make
a new Object(). The problem with it is the same as above, though. We need something
real to lock on, and I don't think the AxisHttpSession will do it. Perhaps we should
add getLock() and releaseLock() APIs to the Session APIs.
> Glen - got kicked off of irc but I think the problem would be
> solved by
> something like this:
> String lockObject = null ;
> Object service = null ;
> sync (session) {
> Hashtable locks = session.get("AxisLocks");
> if ( locks == null ) session.set("AxisLocks", locks = new
> Hashtable() );
> if ( (lockObject = locks.get(serviceName)) == null )
> locks.put(serviceName, lockObject = new String(serviceName)); //
> String can be anything
> }
> sync(lockObject) {
> service = session.get(serviceName);
> if ( service == null ) session.set(serviceName,
> service=getNewService(...));
> }
>
> The first sync would only allow one thread to modify the
> locks hashtable at
> a time - which is ok since the updates to the table would not
> be recursive
> at all. And the second sync would prevent multiple hits to
> the exact same
> c'tor within the desired scope - rather than _any_ c'tor in
> the scope like
> it is now. So, this would lift the restriction that a c'tor
> can't call a
> web service on the same server, but it won't allow the c'tor
> for a service
> to invoke the same service - which I think would be ok - for now :-).
> Whatcha think?
> -Dug
>
>
