> The InterruptedException can be ignored completely i guess. But it is such
> an rare case that that would
> happen.

Is it? If you give up the lock by calling wait, and another thread
accesses it in the mean time (1 sec window), it will happen.

no that exception is thrown when you  take another thread instance and call interrupt() on that
when that thread is in wait. I haven't seen that exception happening in all my java coding years (that i know of)

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!)

Yeah, ok. I'm starting to understand now. So what it would guarantee
is that processing on one box is properly synchronized. It doesn't
guarantee much in a clustered environment, right?

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.

But this is not just for properly synchronizing.. It really has its use because this did happen:
one request comes in that wants the active version. In the mean time there is another that rollbacks the thing.
So suddenly the first request could access the component right. But then the second rollbacks and the component
thats getting processed in the first is suddenly removed from the page. Very strange nullpointers you get then...


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