sync calls versus async calls

[Arthur Blake]

For years now, I've been of the opinion that there is no reason
whatsoever to use Ajax synchronous calls (that's an oxymoron!)

But... I just found one special case where synchronous json-rpc calls
really are necessary:

If you need to save some kind of state back to the server when the
page is unloaded (in the onbeforeunload window handler) async calls
don't work! Presumably because the browser unloads and shuts down
everything so fast, it doesn't have a chance to get the call out.
Using synchronous calls here causes the shutdown process to block
until the call gets off (and returns.)

Here is more information:
http://www.hunlock.com/blogs/Mastering_The_Back_Button_With_Javascript

I suppose I should have known this (one article I found mentioned that
this is somewhat common knowledge) but I haven't come across this
situation up until now.

I was thinking about removing the ability to do synchronous calls in a
future version of jabsorb, but now I'm thinking not...

Developers should know when to use synchronous and when to use
asynchronous calls. I still believe you should be using asynchronous
calls for 99.999% of your json-rpc calls- but I just found one special
case where that doesn't make sense-- maybe there are other cases out
there too....

[Russell Jones]

Arthur Blake wrote:
> Developers should know when to use synchronous and when to use
> asynchronous calls. I still believe you should be using asynchronous
> calls for 99.999% of your json-rpc calls- but I just found one special
> case where that doesn't make sense-- maybe there are other cases out
> there too....
>

Perhaps using synchronous calls should cause an exception on completion
with the returned value as a property. That would not be a problem in
the scenario you mention. And perhaps more to the point, if you really
wanted to use them you could put them in a try-catch statement. The
exception message should be informative, indicating that they should not
be used apart from in particular circumstances. This would help disuade
newbies from misusing them, but not prevent their use when necessary.

Russell

[Russell Jones]

Just thought of this after sending: perhaps asynchronous call style
should be enforced, but a method used to turn synchronous calls on and
off. Ideally assignation of the return value (always null?) would cause
an exception, but I'm pretty sure it's not possible.

[Arthur Blake]

I like your ideas.

Perhaps,

1. Starting with jabsorb 1.4, attempting to use synchronous calls in
the form that they exist now will fail and throw an exception.

2. But we will add a new API flag that can be set client side to re-
enable them for older code that depends on it. At least this way the
developer has to consciously know that they are enabling something
that isn't recommended. Alternatively we could just tell people that
want to use synchronous calls to use the 1.3 client which (most
likely) will still be compatible (and probably even included) with the
1.4 server.

3. We add a new method of making a synchronous call... something like
jsonrpc.syncCall("methodName").doStuff(...) Again with this, it's
clear that the developer has to consciously know that they are doing
synchronous calls and therefore, hopefully think a little bit more
about the ramifications.

[William Becker]

It's been a while since I did it, so my memory is a bit foggy, but on the trunk this is mostly the behaviour that is currently implemented.

1. Starting with jabsorb 1.4, attempting to use synchronous calls in
the form that they exist now will fail and throw an exception.

This happens.
 

2. But we will add a new API flag that can be set client side to re-
enable them for older code that depends on it.  At least this way the
developer has to consciously know that they are enabling something
that isn't recommended.  Alternatively we could just tell people that
want to use synchronous calls to use the 1.3 client which (most
likely) will still be compatible (and probably even included) with the
1.4 server.

You can do this by setting jabsorb.allowSyncCalls = true;
 

3. We add a new method of making a synchronous call... something like
jsonrpc.syncCall("methodName").doStuff(...)  Again with this, it's
clear that the developer has to consciously know that they are doing
synchronous calls and therefore, hopefully think a little bit more
about the ramifications.

This doesn't sound like a bad idea.

[Arthur Blake]

I don't think you have to worry about synchronous calls going away altogether, as we have identified valid uses for them, even if they are not wise to use in most cases.

It's interesting to hear that you are using jabsorb and DWR together.  I've never heard of anybody doing that.  Thanks for the feedback.

On Thu, Apr 1, 2010 at 12:14 PM, Richard Faber <rich...@gmail.com> wrote:

On Feb 27 2009, 1:45 pm, Arthur Blake <arthur.bl...@gmail.com> wrote:
> If you need to save some kind of state back to the server when the
> page is unloaded (in the onbeforeunload window handler) async calls
> don't work!  Presumably because the browser unloads and shuts down
> everything so fast, it doesn't have a chance to get the call out.

> Usingsynchronouscalls here causes the shutdown process to block

> until the call gets off (and returns.)

I currently use jabsorb-1.2.2 in production along with DWR to do
Comet.
Unfortunately I started using synchronous in the early design of a
financial
website... and it totally does rely on "state" to optimize when to
send new
prices...and do database lookups... and it is way to complicated to
migrate
to async.  I tried it once... everything blew up... and went back to
the old
trustworthy synchronous... which has worked totally reliably with
minor
browser mini-hang issues.   For now I'm stuck with it.  I am just
hoping you
make it easy to stay with Jabsorb... beyond 1.3.1, while only using
synchronous.
I could care less about some other features you are planning.... But
Comet is
way cool.   I use DWR+Jabsorb+JQuery  (All 3 do Ajax)... But I still
like jabsorb
because it is JSON (compared to DWR).  I love JQuery... but it has no
Comet.
Just a user giving some feedback...
And thanks for such a nice "Simple" JSON Ajax tool.
I was first into json-rpc because of its simple examples and easy to
demo.
I was first into DWR because its simple examples (in the Comet area).
And JQuery is awesome...  Its a nice team of tools.
Thanks again for all your hard work.