Re: Client issues an RPC before another RPC has finished

[Supercobra Thatbytes]

If you use an MVP pattern this should solve your problem. In this pattern RPCs are issued from the Presenter (Activity in GWT). Each time a user changes Place (URL) the current Activity is destroyed and a new one is created by the new Place for the new view. RPC callbacks that point to the old Activity are discarded silently.

More about places and activities in GWT:

 https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces

On Friday, November 23, 2012 12:04:13 PM UTC-6, Alexey Panteleev wrote:

Hello,

 I've been struggling with this issue for a long time, maybe someone could help me address this finally?

From time to time it happens that a user navigates to one page wich issues an RPC to our server but then quickly navigates to another page which issues yet another RPC to the server while the 1st call is still being processed by the server. In this case I always see some kind of SQLException on the server side (I guess for the 1st call) and then the client also receives an unspecified Exception. 

 What is the best practice for dealing with these situations? Should I be canceling the 1st call before allowing the 2nd one?

We use gwt-dispatch, I did not find  a cancel method in that framework yet. Or should I not allow any new calls until the active one has not finished?

 Do you ever run into this w/ GWT?

Thanks much,

Alexey

[Jens]

If you see SQLExceptions just because the user navigates too quickly you should analyse and fix your server code / database setup / querys!

When you have solved this your only "problem" now is that both RPC callbacks will be executed once their corresponding RPC request returns and this may cause odd behavior in your UI if not handled. You have to detect when a user leaves a page and store that fact in a field (e.g. boolean isActive). Your callback should then check this field before executing its onSuccess() code.

Using GWT Activities you would set the flag to true in Activity.start() and to false in Activity.stop() and Activity.cancel().

Following the documentation for GWT-RPC you could also let your methods return "Request" instead of "void", e.g.

interface MyServiceAsync {
  public Request myMethod(String s, AsyncCallback<String> callback);
}

this allows you to cancel the request on the client side (server will still do its work once the request reaches the server).

-- J.

[Alexey Panteleev]

Hmm, I do use MVP and I switched to Activity&Places on another project, still using a home grown Presenter+Viewer framework on this project.

My AppController creates a presenter each time for a new location:

new ViewPresenter(clientFactory).go(container);

The presenter may issue: clientFactory.getRpcService().execute(...)

But when a user navigates to another location the presenter is probably not destroyed

The new location would do: new View2Presenter(clientFactory).go(container)

And the 1st presenter would get destroyed only when the 1st location is revisited. That is when the view.presenter variable is reset.

Hmm, I need to think about this more.

Or maybe I should simply enable the Activity/Places framework for this project also.

Thank you

[Alexey Panteleev]

Hi Jens,

 What I get for the SQL exceptions are either this:

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed.

or 

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed.

or

java.sql.SQLException: Operation not allowed after ResultSet closed

or

java.lang.NullPointerException: null

at com.mysql.jdbc.ResultSetImpl.findColumn(ResultSetImpl.java:1133) ~[mysql-connector-java-5.1.21.jar:na]

All seem to relate to the db connection closed. Just trying to wrap my mind around how exactly the connection is closed/lost if my persist thread is still working, trying to extract the data.

Thank you,

Alexey

[Alexey Panteleev]

Ok, I think it's a good idea for me to switch to the Activity/Places framework on this project also.

So the things like that are handled by the framework automatically.

Supercobra is actually saying I wont have to worry about setting that isActive flag as the Activity will get destroyed all together.

On Saturday, November 24, 2012 10:44:11 AM UTC-8, Jens wrote:

[Alexey Panteleev]

Jens, what if instead of using the isActive flag I check "view.asWidget().isAttached()"?

That will return true only if the presenter's view is active, right? I actually use this in one place already successfully.

On Saturday, November 24, 2012 10:44:11 AM UTC-8, Jens wrote:

[Alexey Panteleev]

On the other hand I am thinking, is the activity really destroyed, if there is already an active RPC listener?
That is an external reference to the Activity object so the GC would not touch it, right?

[RickL]

Alexey,

FWIW, I would do as Jens suggests.  It is not difficult to implement and it is reliable.

Rick

On Friday, November 23, 2012 12:04:13 PM UTC-6, Alexey Panteleev wrote:

[Alexey Panteleev]

I’ve been debugging this one some more. It’s the SQLException that is really puzzling me.
I also see that it is not the location change per se that is causing it but navigating to the same #location twice:

• navigating to another location and then back to the same one while the 1st RPC is still executing
• or reloading the browser page while the 1st RPC is still executing
  

Thank you for the suggestions.

Need to debug more to see what exactly is happening on the server side in this situation.

[Alexey Panteleev]

Ok, I found my Servlet problem. For some reason I assumed that my request processing object is re-created for each request and I can safely use the object variables to store a current persist/db connection. Just realized that the object is created only once and the execute() method was overriding the persist/db connection variable whenever a new request came.

Now I can improve the client side.
Thanks a million for flagging this one for me.