Server action delay

[liudi]

Hi Iso,

i m currently facing a waiting time problem of RPC calls.

The scenario is that when a user logs on, this user will be navigated to another Layout (a java class), at the top of the class, it retrieves the user information in the session to populate some form items like a combo box. I store the login user information in a Map<String,String> in order for later use.

this is done by calling 'getLoginUser(Map<String, String>) as below:

public static void getLoginUser(final Map<String, String> loginUserMap) {
		
		DSRequest request = new DSRequest();
		request.setOperationId("getLoginUser");
		Criteria cri = new Criteria();
		final DataSource dsLoginUser = DataSource.get("user_table");
		dsLoginUser.fetchData(cri, new DSCallback(){
			public void execute(DSResponse response, Object rawData, DSRequest request) {
				SC.clearPrompt();
				Record loginUser = response.getData()[0];
				String [] attributes = loginUser.getAttributes();
				for(int i = 0; i < attributes.length; i ++) {
					String attr = attributes[i];
					String val = loginUser.getAttribute(attr);
					loginUserMap.put(attr, val);
				}
			}
		});
	}

To retrieve the needed combobox options, form item visibility flag, i tried to pass the loginUserMap into another RPC call, like this:

private Map<String, String> loginUserMap = new HashMap<String, String>();

... ...

public Constructor() {
   getLoginUser(this.loginUserMap);
   getFormInfo(this.loginUserMap);
}

the getLoginUser takes time to get the data back from the server to fill the loginUserMap, so when it calls getFormInfo(loginUserMap), it throws a null value exception.

is there any way that can prevent this from happening? getFormInfo should not be executed if the getLoginUser is not finished.

Thanks!

P.S. a timer is not good because nobody can predict how long it will take

[tdoty]

Actually, a Timer (http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/user/client/Timer.html) is just what you are looking for.

I needed something similar to ensure that the server calls were completed to fill in values for GUI components before the user could see/interact with them.

If you aren't sure how to use this class (it's pretty simple actually), just do something similar to the following...

              Timer timer = new Timer() {

                public void run()
                {
                  if(first RPC call has returned) {
                    make your other RPC call here
                    cancel();
                  }
                }
              };
              
              timer.scheduleRepeating(some arbitrary number of millis);

I simply used a "countdown" approach for my solution. I would increment the counter before an RPC call, and decrement it once the RPC call returned. Just poll that counter and go ahead once it is at zero. Obviously this isn't the only way, but it should work for what you need.

Let me know if you have any questions.

[jay.l.fisher]

Why not just put the code that creates and shows the new Layout inside the login callback?

[tdoty]

Ahh yes, that would be much easier. I guess I was thinking of an example where the two loads were happening independent of each other, and one had to wait on the other to continue. But that is not likely the case for the original issue, so just making the RPC call in callback would be a much better solution.

It's too early to be doing any logical thinking. =P

[liudi]

thanks for the reply guys.

tdoty, i don't think timer is a good idea because the timer is not event triggered, and once the waiting time is set, it can't be changed. In a live system, anything could happen to delay the server response, no matter how large the number you put in the timer, it's still not guaranteed, and how long can the users wait?

jay, putting the code inside login callback makes the code very ugly and hard to manage, it causes problems too. what if you have a list of actions to perform to get certain values? that would be a complex nested callback hierarchy.

I think there must be a better solution. what GwtExt does is that the caller will wait until the called function returns something. In my case the second method will hold till method one returns a value(even a null value, but returned by method 1). I guess SmartGwt must have the same functionality (it actually should be GWT, right?), but i just don't know it yet :)

[Isomorphic]

It sounds like you're expecting RPC requests to be synchronous. This is not the case

Standard SmartGWT RPC Requests are asynchronous.
In other words when a request is issued, it will be sent to the server, and the thread of execution will continue.
When the server responds to the request, any callback passed into the request is fired in a separate thread.

So Jay's suggested solution - using the request callback to trigger logic that depends on data returned by the server - is appropriate.

In terms of application design, this really isn't too difficult to work with. If you need to load some remote user information on startup its easy to issue and initial request for this information, and then fire a method to build the main application UI when the request returns. If you need to issue multiple requests, if you're using the SmartGWT server you can make use of request queuing to avoid more HTTP transactions than are necessary and be guaranteed that the response callbacks will fire in order.

[liudi]

Thanks Iso, i think i just got some wrong memories from my previous GwtExt project. thanks Jay for your suggestion, i m using it, and working well!

[r.beelagi23]

can you post your callback code?