Re: 2 phase commit: performance implications?

>Why not just query adjacent databases, rather than copying the data around?

The reasons I didn't choose this way were:
1) I didn't think there's a way to write a query that can act on the data in
two
Databases as though it was all in one, and I didn't want to get into merging
multiple database query results on the Application side. I'd rather just
have all the needed data sitting in a single database so that I can perform
whatever query I like without complication.
2) Most database accesses are reads, and I didn't want a big network
overhead for these, especially since I'm aiming for each database to be
entirely RAM resident.

>If you really wanted to do this, do you need 2pc?  Once data has been
uploaded to the database for region A, then asynchronously copy the data to
B, C, D and E later, using a queue. 

I've always assumed that my data needed to be consistent. I guess there are
some circumstances where it isn't really a problem, but each would need to
be carefully evaluated. The easy answer is to say 'yes, it must be
consistent'.

>If you try to commit to all at once, then if one fails, then none has the
data.

Yes, I'd prefer things to be that way in any event.

Regards,
Andy