<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 8:02 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<br>
On December 9, 2015 at 7:07:06 AM, Ira Cooper (<a href="mailto:ira@redhat.com">ira@redhat.com</a>) wrote:<br>
> A simple "abort on failure" and let the higher levels clean it up is<br>
> probably right for the type of compounding I propose. It is what SMB2<br>
> does. So, if you get an error return value, cancel the rest of the<br>
> request, and have it return ECOMPOUND as the errno.<br>
<br>
</span>This is exactly the part that worries me. If a compound operation<br>
fails, some parts of it will often need to be undone. “Let the higher<br>
levels clean it up” means that rollback code will be scattered among all<br>
of the translators that use compound operations. Some of them will do<br>
it right. Others . . . less so. ;) All willl have to be tested<br>
separately. If we centralize dispatch of compound operations into one<br>
piece of code, we can centralize error detection and recovery likewise.<br>
That ensures uniformity of implementation, and facilitates focused<br>
testing (or even formal proof) of that implementation.<br>
<br>
Can we gain the same benefits with a more generic design? Perhaps. It<br>
would require that the compounding translator know how to reverse each<br>
type of operation, so that it can do so after an error. That’s<br>
feasible, though it does mean maintaining a stack of undo actions<br>
instead of a simple state. It might also mean testing combinations and<br>
scenarios that will actually never occur in other components’ usage of<br>
the compounding feature. More likely it means that people will *think*<br>
they can use the facility in unanticipated ways, until their<br>
unanticipated usage creates a combination or scenario that was never<br>
tested and doesn’t work. Those are going to be hard problems to debug.<br>
I think it’s better to be explicit about which permutations we actually<br>
expect to work, and have those working earlier.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a></div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Could we have a dry-run phase and a commit phase for the compound operation.<br></div><div class="gmail_extra">The dry-run phase phase could test the validity of the transaction and the commit phase can actually perform the operation.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If any of the operation in the dry-run operation sequence returns error, the compound operation can be aborted immediately without the complexity of an undo ... scattered or centralized.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But if the subsequent operations depend on the changed state of the system from earlier operations, then we'll have to introduce a system state object for such transactions ... and maybe serialize such operations. The system state object can be passed through the operation sequence. How well this idea would work in a multi-threaded world is not clear to me too.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>