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 ....'

Its exactly that. You have to have a lock on the monitor to call wait.
When you start waiting you don't lock in anymore so others can take the lock
and also see that they also have to wait and start waiting.

Then the first thread that calls notifyAll() on the monitor lock (where the other 2 wait on)
will wake them all up. But the first one that comes out of the wait takes the lock again
so the second one first have to wait what the first one that did come out releases the lock again
(by going out of the sync block or again in the wait)

The InterruptedException is completely different thing. That is i guess the same kind of thing
then object.notifyAll but on a thread that then goes with an exception. But as i said i haven't seen
that happening yet. And i currently don't know of a usecase.

> 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.

yes we do because the interruptedexception will never be called.
And if it will a wicket exception is fine there.

The only thing we can do is wait not for 1 sec but for 10 and if that still isn't enough
then we have a bug in wicket code and throw an exception or something.
then at least the request will be finished instead of in a completely halt.

> 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?

that is impossible. We can only sync on the things in one vm we don't have control over anything else.
So what we do now is the best we can.

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?

that would mean a big rewrite currently
Because the getPage() is called before there is an RequestTarget..
And also the detaches (which calls page.detach()) of the RequestTargets is called completely outside
the request/response phase of a request target.

So if we want to fold it completely into the RequestTarget then there has to be a major rewrite
just look at:

DefaultRequestTargetResolverStrategy.resolveRenderedPage (final RequestCycle requestCycle,
            final RequestParameters requestParameters)

and then start with the PageExpiredRequestTarget ... how would you create that target.. without trying to get the page :) (or better :( )


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