No more: could not aquire lock on @Sycronized errors

[luxspes]

After playing with the value of Synchronized.DEFAULT_TIMEOUT (thanks to my ConfigurableSynchronizationInterceptor) I have discovered that a value of around 1 minute makes my app much more stable: No more could not aquire lock on @Sycronized errors.

It is of course puzzling that this value is hard coded by default (please vote here so that my interceptor becomes part of Seam core), but it is even more puzzling that its default value is 1 second, IMO that makes Seam applications fragile by default. Richfaces global queue helps with some of this fragility, but feels (and works) like a patch, my end users still found ways to make the application crash even after I enabled RichFaces global queue...

I would be very interested in knowing the rationale behind the decision of setting the default value so low (and making it so hard to change it globally)... after I set it to 1 minute I have not seen any adverse effects in performance but maybe there is some unknown problem I should be aware of... I am even thinking about disabling Richfaces global queue... it now seems redundant...

Any opinions?

[kragoth]

1 minute seems an awefully long time to be waiting for a lock. Unless you have got reports or heavy processing happening on a button click.

We farm our heavy processes off to another thread or don't use ajax to make the call. Just lock the app up while the processing goes on. I guess the idea behind the 1 second is that ajax requests should be very light weight. Otherwise you risk getting your page out of synch because the user has control of a page where the information being displayed is not complete.

I do agree that 1 second can still be a bit short for even light weight ajax requests. I've experienced it on a simple list refresh handled by ajax. But, all my problems went away with a single ajax queue.

Ok.... I'm done ranting now. :P

I don't think you should remove your ajax queue. The ajax queue is not there just to stop your synch errors. If you use the oncomplete functionality of the ajax request the queue is still useful. Otherwise you're javascript will be potentially working on a incomplete/partially modified DOM. There's probably a lot of other reasons to stick with the queue too but.... I'm still waking up :P

[luxspes]

Tim Evers wrote on Nov 05, 2009 00:14:


1 minute seems an awefully long time to be waiting for a lock. Unless you have got reports or heavy processing happening on a button click.

Yes, I though that too, at first, I set it to 2 seconds (because I had many cases where I needed to wait for that), then as load increased and more features were tested, I had some cases that needed 3 seconds... then some that needed 4 seconds... then some that needed 7 seconds.... then some that sometimes (low load) needed 3 seconds, and sometimes needed 8 seconds (high load), and then another one that needed 9 seconds, but sometimes it... you get the idea, so I decided to set it to 1 minute, and wait and see if I got any complaints from users... so far, they are completely happy (apparently the risks of having locks wainting 1 minute have a much lower probability of causing problems than the Could not acquire lock on @Synchronized errors. I wonder if that is the case only for my applications of it is something typical of Seam applications...

We farm our heavy processes off to another thread or don't use ajax to make the call. Just lock the app up while the processing goes on. I guess the idea behind the 1 second is that ajax requests should be very light weight. Otherwise you risk getting your page out of synch because the user has control of a page where the information being displayed is not complete.

Yes, that certainly seems like the right thing to do from a theoretical POV, but in practice that means modifing dozens of pages (hundreds of line of code) just because maybe some processes, while under load, is going to take 7 seven seconds instead of 2 seconds. Simply setting it to 1 minute and wainting for complains from the user (and the optimize) seems like a more sensible choice.

I do agree that 1 second can still be a bit short for even light weight ajax requests. I've experienced it on a simple list refresh handled by ajax. But, all my problems went away with a single ajax queue.

Ok.... I'm done ranting now. :P

Yes, ajax queues help a lot, they solved around 75% to 85% of my Could not acquire lock on @Synchronized errors, but setting the default timeout of Synchronized elements seems to have solved the remaining  15% to 25% of my problems...

I don't think you should remove your ajax queue. The ajax queue is not there just to stop your synch errors. If you use the oncomplete functionality of the ajax request the queue is still useful. Otherwise you're javascript will be potentially working on a incomplete/partially modified DOM. There's probably a lot of other reasons to stick with the queue too but.... I'm still waking up :P

I do use the oncomplete to preserve focus, so I guess I will keep my ajax queue for while...

Thanks a lot for answering