On Sat, Apr 16, 2011 at 2:41 AM, Christopher Browne
<cbbrowne at afilias.info> wrote:
> On Fri, Apr 15, 2011 at 2:16 PM, Steve Singer <ssinger at ca.afilias.info> wrote:
>> C)  We could get rid of try blocks.  Some people have commented that
>> they don't behave as expected anyway and with the additional
>> restrictions of changes 1) and 2) they are even less useful.
>
> I'd point not only to "less useful," but also to "less able to be
> reasoned about" as an issue.
>
> The "intuitive" position is that TRY blocks are supposed to look like
> something quasi-transactional; if there's a failure, "everything
> should be rolled back."  That's certainly a cool idea to consider.
>
> Unfortunately, that's not remotely near to being how things are.  If
> there are activities inside a TRY block that cross multiple nodes,
> it's not reasonable to expect that all to roll back.  (We're not using
> 2PC!)

But it does seem to work well enough...

eg. execute a number of SQL scripts in a try block. If one of them
fails when applying to the master, it all rolls back. If they all
work, the events get propagated and they are applied on the slaves and
if this fails you have other problems. It might not be perfect, but it
is better than a kick in the teeth and I would like to keep it.



-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/