On 08/15/2011 03:31 PM, Ian Springer wrote:
On 08/15/2011 01:27 PM, Robert Buck wrote:
> Outbound-filtering was an optimization to avoid unnecessary busywork, to
> reduce CPU load and reduce the number of branches in the code (a
> simplification actually to a single case).
>
> Yes, somewhere have some global state, a static if you will, that is the
> UUID. A mouse-click, e.g., would trigger an update to the UUID
> request-id. This occurs before any RPC request is sent out. But you need
> to make sure that the following holds true:
>
> for each Ei of Ai, all Ui must be identical; that is all causally
> related events MUST use the same UUID
>
> , where E=event, A=action, U=unique-ids.
>
> Bob
In most cases, the Ei RPC requests are sequential, where E1's
onSuccess() handler invokes E2, E2's onSuccess() handler invokes E3,
etc. In such cases, we'd be fine, because if the uuid changed during E1,
when E1 returned, it would drop its response, and E2, E3, etc. would
never get invoked.
However, I'm not sure if there are exceptions to this, where for a given
navigation, some of the requests are initiated in parallel. If there are
any such exceptions, we might need to store away the current uuid at the
time the navigation is initiated and then compare it the current uuid
prior to making the parallel outgoing RPC requests, in order to prevent
these requests from getting assigned the wrong uuid.
One example of parallel RPC requests I can think of off the top of my
head is ConfigurationEditor.onDraw(), which initiates two RPC requests
in parallel - one to retrieve the Configuration and one to retrieve the
ConfigurationDefinition. So there may certainly be other places where we
do it.
The extra processing we'd have to do for parallel RPC requests of within
a navigation action could look something like this for the
ConfigurationEditor.onDraw() case:
// in ConfigurationEditor's constructor, since we know we're going to
make some parallel RPC requests, squirrel away the current action uuid.
this.navigationActionUuid = CoreGUI.getCurrentNavigationActionUuid()
// then in onDraw()...
// for the first RPC call that is initiated, do nothing special. under
the covers, it will call CoreGUI.getCurrentNavigationActionUuid() to
grab the current uuid and stick that into a request header
ResourceTypeRepository.Cache.getInstance().getResourceTypes(new
Integer[] { resourceTypeId },
EnumSet.of(ResourceTypeRepository.MetadataType.resourceConfigurationDefinition),
new ResourceTypeRepository.TypesLoadedCallback() {
... });
// for all subsequent RPC calls made in parallel, pass the squirreled
away uuid in to the RPC proxy, to tell the proxy that all calls made
through it should stick that uuid into the request, rather than the
current uuid (i.e. CoreGUI.getCurrentNavigationActionUuid()). This
prevents the wrong uuid (a uuid from a more recent navigation action)
from being placed in the request. alternatively, if the passed-in uuid
does not equal the current uuid, the proxy could not send the request at
all.
ConfigurationGWTServiceAsync configurationService =
GWTServiceLookup.getConfigurationService(this.navigationActionUuid);
configurationService.getResourceConfiguration(asyncCallback);
However, I don't think it is ultra critical to deal with the parallel
call cases, because it's probably not going to be often that the user is
quick enough to navigate somewhere else before the view has a chance to
kick off all of the parallel calls.