To fix the latency iduced performance issues in the network RAs, both
ra_svn and ra_dav need to implementing pipelineing. To do that, it is
my conviction that at least the delta editor must be specified to
operate in an asynchronous manner. By asynchonous I mean that when you
call a delta editor method, you cannot be sure that the operation has
completed by the time the method returns. If an editor methon returns
success, it does not guarantee that the operation really did succeed
(e.g. at the other end of a network). There is nothing that really
forbids this behavious right now, but I think it should be explicitly
documented. In case I was not clear enough, here's an example:
...
1. call editor->open_file(file1)
2. call editor->apply_textdelta
3. call editor->close_file
4. call editor->open_file(file2)
...
Consider that the first open_file failes at the other end. With
synchronous operation, open_file would return an error. With
asynchrounous operation the error from open_file can be delayed until
any later operation, e.g. the second open_file above.
Asynchronous operation has a few implications on error handling. For
synchronous operation, the editor driver can easily handle an error, but
for asynchronous operation, it is very hard to do for the following reasons.
1. If an error is returned on the driver side, how can it know which
operation that failed?
2. If the receiver encounters an error and sends a reponse, it is
possible that the driver has already sent more requests, and
those requests may be depending on the success of the operation
that failed.
I see a few ways to handle these problems:
A complex solution would be to introduce some form of transactions, but
I belive that such a solution would be overkill.
A simpler solution is to define the following "rules":
1. If a delta editor operation returns an error, the editor is dead
(or wedged, or in an error state or whatever you want to call it).
2. When the delta editor is dead, further operations are ignored by
the receiver (and the driver must call abort_edit since every
other operation is ignored anyway).
If it is required to handle the errors of the editor operation in an
operation dependant way, it can be solved by adding a callback and a
baton to each operation that is called when that operation completes.
This would uglify the editor interface a bit, so it should not be added
unless it is really needed.
Do you see any reasons why the simple solution would not work?
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 25 13:16:10 2003