> no that exception is thrown when you  take another thread instance and call
> interrupt() on that
> when that thread is in wait.

Well, if another request comes in for the same session, that is
exactly what happens, right?

Maybe I don't understand it properly, but this is from the javadocs of

' The current thread must own this object's monitor.
This method causes the current thread (call it T) to place itself in
the wait set for this object and then to relinquish any and all
synchronization claims on this object.'

and 'The current thread must own this object's monitor. The thread
releases ownership of this monitor ....'

> The question i have now that comes to mind when that happens does it first
> wait again for getting the lock?
> or are you suddenly in a sync block without a lock?? (that would be bad!
> because if it is then i Need to throw
> that exception else i test a map that isn't synched on!)

That's twhy I wondered whether we are synchronizing properly.

> If you don't use sticky sessions you are right
> But none sticky sessions with a session that has attributes which can change
> on all sides are borked anyway.
> That will never work. except in a VERY expensive way and let the cluster do
> a sync over all the servers....
> but that would completely terminate the performance gain (if any) that you
> have by not using sticky sessions.

That's probably true, but that doesn't mean we have to write with that
assumption in mind. If we can write something that would just work,
wouldn't that be better?

I think it would help if we somehow would be able to bring this
problem back to request targets. For instance if the resolving of a
request would be synchronized on the session, and from then onwards
just on the lock that request target produces. What would be problems
with that approach?


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to