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: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of levani
dvalishvili
Sent: Sunday, June 15, 2008 4:23 AM
To: [email protected]
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
