http://www.udev.info
Mail/Login: Password : forgot my password!
[UPDATE MODE]
Back

Trouble with massive Ajax requests and the Uniface state table

Direct link http://www.udev.info/uniface/trouble-with-massive-ajax-requests-and-the-uniface-state-table
Written by -GHAN- // Tags: ustate ajax collision lock db

Ajax Ajax Ajax ... what a wonderful thing! As we get busy with it and choose to handle the session state by a StateManagerComponent things can turn bad..

The session state

A stateless environment like the web is not as easy to handle as a statefull one. The user is disconnected and on every request reconnected (or at least he should be).

Uniface offers different ways to manage this. The most clever one is to save the state to the StateManagerComponent. It takes the values and stores them to the database. Let's look at part of a typical SetState trigger (e.g. here from a DSP):
SOURCE CODE
Sorry- ... please log-in or register to get this!

Before this block ends, the component "USYSSTAT" is activated to save the state. In the default setting, the complete list of variables are stored and remain until the next GetState takes care of them offering you to know, what happened before and just continue seamless after loading the values.

Causing panic!

Saving the session is in theory a nice thing to do and also necessary. And yet we have stay aware of this could lock down the database in some situations. Here comes the scenario, which easily can be done with every USP or DSP using the USYSSTAT or similar.

Welcome to Async-Land!

Imagine a complex web project. Changing a widget somewhere causes to reload let's say some text, 3 valreps and some other data. As these requests are asynchronous the are made independend from another.
So while we change the widget, we launch 5 requests via Ajax using the same instance to fetch the needed content.

As we know, some triggers are ALWAYS fired. SetState is definitely one of them. And so, every of these 5 requests want to safe the state for $instancename nearly the same time. This will get the database into a lock, blocking everything while the request is handled and changing the state according to the first request. The other requests can't finish as the occurence is "LOCKED". After all only the first and maybe the second request are handled as desired while the others remain running (commonly max 300secs) until they have been able to store the state! Your interface is not updated correctly and could show some unpredictable behavior.

The most ugly detail in that is that this example is pretty realistic! (and I definitely had my trip to Async-Land :) )

Turning the tide

Now we know, whats going wrong. Let's get back in control an fix it. The fix is pretty easy but has to fit your needs. As the problem occurs in the SetState, we need to get our hands on it. Further we know those DYNAMIC requests can run into trouble if they are to many and the same time.

If we could say: "I do something dynamic/ajax to fetch the data- then I do NOT need to update the state" here is the fix:
SOURCE CODE
Sorry- ... please log-in or register to get this!

This example isn't meant to be the best shot but it will surely give you some inspiration on how to handle the problem.

In my case I was able to change the Ajax requests to carry an extra value. This "NoStateUpdate" mode solved the problem as the state only was saved on FULLPAGE or SAVE-SOMETHING-IMPORTANT requests.

Hope this works for you, as it did for me.

Comments

912 view(s) / 2010-02-22 14:17:49 / LAST UPDATED: 2010-09-29 11:33:58