On Sat, Nov 7, 2015 at 12:07 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: > > The previous patch would not compile on the latest HEAD. Here's updated > > patch. > > Perhaps unsurprisingly, this doesn't apply any more. But we have > bigger things to worry about. > > The recent eXtensible Transaction Manager and the slides shared at the > Vienna sharding summit, now posted at > https://drive.google.com/file/d/0B8hhdhUVwRHyMXpRRHRSLWFXeXc/view make > me think that some careful thought is needed here about what we want > and how it should work. Slide 10 proposes a method for the extensible > transaction manager API to interact with FDWs. The FDW would do this: > > select dtm_join_transaction(xid); > begin transaction; > update...; > commit; > > I think the idea here is that the commit command doesn't really > commit; it just escapes the distributed transaction while leaving it > marked not-committed. When the transaction subsequently commits on > the local server, the XID is marked committed and the effects of the > transaction become visible on all nodes. >
As per my reading of the slides shared by you, the commit in above context would send a message to Arbiter which indicates it's Vote for being ready to commit and when Arbiter gets the votes from all nodes participating in transaction, it sends back an ok message (this is what I could understand from slides 12 and 13). I think on receiving ok message each node will mark the transaction as committed. > I think that this API is intended to provide not only consistent > cross-node decisions about whether a particular transaction has > committed, but also consistent visibility. If the API is sufficient > for that and if it can be made sufficiently performant, that's a > strictly stronger guarantee than what this proposal would provide. > > > > On the whole, I'm inclined to think that the XTM-based approach is > probably more useful and more general, if we can work out the problems > with it. I'm not sure that I'm right, though, nor am I sure how hard > it will be. > If I understood correctly, then the main difference between 2PC idea used in this patch (considering we find some way of sharing snapshots in this approach) and what is shared in slides is that XTM-based approach relies on an external identity which it refers to as Arbiter for performing consistent transaction commit/abort and sharing of snapshots across all the nodes whereas in the approach in this patch, the transaction originator (or we can call it as coordinator) is responsible for consistent transaction commit/abort. I think the plus-point of XTM based approach is that it provides way of sharing snapshots, but I think we still needs to evaluate what is the overhead of communication between these methods, as far as I can see, in Arbiter based approach, Arbiter could become single point of contention for coordinating messages for all the transactions in a system whereas if we extend this approach such a contention could be avoided. Now it is very well possible that the number of messages shared between nodes in Arbiter based approach are lesser, but still contention could play a major role. Also another important point which needs some more thought before concluding on any approach is detection of deadlocks between different nodes, in the slides shared by you, there is no discussion of deadlocks, so it is not clear whether it will work as it is without any modification or do we need any modifications and deadlock detection system and if yes, then how that will be achieved. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
