Hi Levancho, This option is very old, dating back to the earliest versions of RemoteObject client code and it may not do what you're expecting it to do. The documentation here isn't very clear (although it's not a simple topic so maybe that's why). When you set this to "last", you're telling your RemoteObject instance to ignore results/faults that return to the player for any earlier calls you've issued before the currently final call, but this doesn't have any effect at the network level. What this means is that if you make multiple calls quickly like so:
ro.foo(); ro.bar(); Both calls will be sent to the server but the result/fault for foo() will return to the player and the RemoteObject will just discard it rather than dispatching a result or fault event to your handler code. The result/fault for the second call to bar() (the "last" call you've made) will be dispatched. So this option doesn't cancel out the call at the network level. That's not even possible. Once a request is put on the network, there's no way to cancel it apart from waiting for its result/fault to dispatch in the player, and if the call succeeded, meaning you get a result rather than a fault, you'll need to make an explicit compensating/rollback call to undo or cancel what you've just done. So you'd have: ... fooToken = ro.foo(); ... <oh no, I want to cancel or undo foo.. set a custom flag on my token to control how I handle the eventual result/fault> ... fooToken["undo"] = true; ... <within my result handler, check for this custom flag I added to the AsyncToken for my call>... if (token["undo"]) ro.undoFoo(); // Make a call to rollback whatever foo() did, and don't bother processing the result. else processResult(result); ... <otherwise, in my fault handler>... if (!token["undo"]) processFault(fault); * Just to be clear, that's psuedocode to just illustrate the idea. If you're happy with the player just not dispatching the results/faults it's receiving for earlier calls to your handler code (they're still all being processed at the server), feel free to log an enhancement to get the 'concurrency' property supported on non-MXML RemoteObject. I'm not sure why it was only implemented for the MXML version. Hope that helps, Seth From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of levani dvalishvili Sent: Sunday, June 15, 2008 4:23 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] [BlazdeDS] setting concurrency property through actionAcript Hi all, in this document : http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=rpc_07.html it says you can You can set the concurrency property on a RemoteObject component's <mx:method> tag but I don't use method tag, does that mean I cant set concurrency to be "last" ? how can I tell my remoteCall to use concurrency ="last"? I use following code to invoke remote Object : var token:AsyncToken = roService.getQuickPickList("12345"); token.addResponder(new AsyncResponder( function(data:Object, token:Object):void { // lalala }, function(info:Object, token:Object):void { }, token )); basicaly I want to make sure every subsequent request cancel out any existing request currently running .looks like that concurrency property will do just that, but I cant seem to find where I can set that all suggestions are appreciated Kind Regards levancho