If you've ever used a PL/SQL dynamic action with the default 'wait for result', you would have seen the following warning if you have the browser console open.
 |
| Text for bots: Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. |
Consider this scenario of dynamic actions on change of P42_ITEM:
 |
| Synchronous vs Asynchronous server calls |
First JavaScript takes value of P42_ITEM, concatenates a letter and places result in another field. Let's say I entered "X":
$s('P42_NEW2', $v('P42_ITEM')+'a');
The value in P42_NEW2 would be "Xa"
The PL/SQL code concatenates another letter, passing current value of P42_NEW in and out of session state via page items to submit/return:
:P42_NEW2 := :P42_NEW2||'b';
The value will now be "Xab"
The second JavaScript concatenates another letter:
$s('P42_NEW2', $v('P42_NEW2')+'c');
On page load the value of P42_NEW2 would be "ac", since both JavaScript actions default to 'Fire on page load'.
If 'Wait for Result' on the PL/SQL action is 'yes' (default), then the communication will be synchronous and the JavaScript will only execute once the PL/SQL is finished. The final value would be "Xabc"
If the PL/SQL action 'Wait for Result' is set to 'No', then the subsequent JavaScript will execute immediately, not, um, waiting for a result. The value of P42_NEW2 would briefly be "Xa", then just "c" until the PL/SQL returns with "Xab".
 |
| Asynchronous DA result |
Think about that. This impacts how you structure dynamic actions, pose questions to the user, and steer application workflow. Regression testing will be required when updating compatibility of your existing applications to 5.1.
In a tweet by John Snyders, who has posted some amazingly detailed posts on the inner workings of APEX, he suggested we can soon forget there was any other way.
I understood this to infer that synchronous actions would disappear. That screenshot is from 5.1 EA1, so it seems they're hanging around for now. It could be considered a backwards compatability thing, though it's still the default option. I'd say many applications would not work as expected should this behaviour disappear.
Synchronous activity on a website is usually non-preferrable for good UX, I understand that's inciting the change in the nature of the inherent browser behaviour (ie: the warning above). As far as I understand it, the way the APEX team has mitigated this warning is by modifying the JavaScript call to the PL/SQL callback as follows:
apex.server.process
("CB_AJAX" // name of AJAX callback
,{x01 : $v('P42_ITEM')}
,{async: false // deprecated synchronous option
,success: function(pData) {
// deprecated wait for result
$s('P42_NEW2', pData + 'c');
}
).done(function(pData) {
// 5.1 wait for result
// ...
});
Well, this is the jQuery method for
deferred callbacks. In future this will be done natively as promises. I've previously detailed some
sample code on these variations.
So the end result to the developer appears to be very little, though I'm sure there were plenty of tweaks in the engine to make this happen. Though it does protect applications from when browsers
do decide to no longer support the async parameter.
Edit: The end result for the user, as per John's comment, is the browser will
not be locked up whilst waiting for the result. This behaviour probably
will result in some behaviour differences in some applications, time will tell. Be on the lookout for it.
Actions are no longer synchronous, but you can still have JavaScript execute only after the PL/SQL finished.
