Re: Re-firing a failed/rejected server call in RequestFactory, is this possible?

The inconsistency with the current RequestFactory is that if in a batch request, a single sub-request has a constraint violation

then onConstraintViolation is called for every sub-request and the whole batch request fails (onFailure is called).

Whereas if in a sub-request an exception is raised on the server only for this single sub-request onFailure is called and the surrounding

batch-request succeeds with onSuccess.

Thus, the RequestContext cannot be reused since "reuse" is only called for constraint violations and failures.

Hence, as described in the original post, after a server failure the proxy cannot be reused and the user-entered data is gone (in contrast to a constraint violation).

Am Dienstag, 26. November 2013 15:04:04 UTC+1 schrieb Thomas Broyer:

On Tuesday, November 26, 2013 1:56:35 PM UTC+1, Jan Marten wrote:

Is there any progress on this issue?

Issue https://code.google.com/p/google-web-toolkit/issues/detail?id=5794 is related and is not fixed either.

RF's behaviour in this regard is inconsistent since an "unimportant" retrieval would fail on any ConstraintViolation

in batched requests. It should definitely be possible to batch requests but the current API is not sufficient.

A recommendation would be to pull batching out of the RequestContext interface and expose it in e.g. a RequestContextBatcher.

A RequestContext is used for one request only and is reusable on failure or violation. Thus removing append(), fire(Receiver), etc.

RequestContextBatcher is used for multiple requests.

The specific behaviour in onFailure and onViolation should be discussed further.

The current API has batching built-in: one RequestContext instance == one batch request. You're free to use batches that only contain a single invocation.

 

Transaction settings might make it necessary for all RequestContexts to be re-executed or to only re-execute the failed/violating requests.

Therefore it must allow customization by the user.

RF assumptions are that:

• for a given HTTP request, there's only one instance for each entity (an entity shouldn't have 2 instances in the same request handling; see https://code.google.com/p/google-web-toolkit/issues/detail?id=7341). That generally means using "cache" scoped at the request, which translates to using the "session per request" (aka "open session in view") pattern.
  
• there's one transaction for each "service method", so that each one can fail independently of the others. If that's not what you want, then create a specific "service method" that does all your work that should be executed in a single transaction.

This is not going to change (what might change is the restriction that one proxy can only be edited by a single RequestContext at a time, which is discussed in the issue you linked to)

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.