AJAX Response Race Condition

| By Webner

AJAX Response Race Condition

I am working on a j2ee project in which a lot of UI screens are AJAX based. Recently we started facing problems on some screens, which were not updating correctly. On one of the screens we have a lot of options with checkboxes to select them. Each checkbox click submits an asynchronous request to the server. While testing we noticed that if we click multiple checkboxes swiftly, the response from server is not processed in expected order.

As an example suppose checking box1 should show 100 in a textbox, while checking box2 should show 200. If I swiftly click box1 and then box2 (before response of box1 is rendered) then I should still see box2’s result as final. I should see 200. But this was not happening. We were noticing box2’s result displayed first and then overwritten by box1’s result.

On analyzing it further we found that response from server was not ordered. Box2’s response was arriving at client side before that of box1’s click (even though box2 was clicked second), hence was being rendered first only to be overwritten by box1’s response. This was not happening always, only in cases when you are fast enough to click options on client side. This is race condition, except that in this case whoever arrives to browser second wins the race.

There are couple of solutions to this problem, if you have more solutions please write.

1. Allow only one AJAX request at a time, wait until it is finished before allowing user to click next. This can be done by using modal wait message window or by using javascript. While this ensures race condition won’t occur, it is not acceptable solution (especially to customers) in all cases.

2. Synchronize method on server side that processes AJAX event to make sure only one thread enters it at a time. This means subsequent threads will have to wait before previous one is done. While this by itself theoretically should solve the problem, it did not in our case. Although the occurrence of problematic situation went down but did not go away altogether. Most probably because if box2 thread enters this method before box1’s thread, result will again be wrong. So an additional thing to do is to put a delay (of say 300ms) on client side (using javascript) between asynchronous requests. Note that no wait message window will show up, this will happen behind the scene. This will make sure box2’s click starts its journey 300 ms later than that of box1. Hence chances of box2’s thread entering synchronized server side method first go down sharply.

This dual fix is working so far on our pages. I will update this blog once getting more experience with the fixes. If you have any suggestions please comment.

Free Online Courses with Certificate
Free Online Courses With Personalized Certificate
Study online, from the comfort of your home
Study online, from the comfort of your home

Leave a Reply

Your email address will not be published. Required fields are marked *