Vladimir, thanks for comments > 2) I would also avoid this flag until we clearly understand it is needed. > All numbers will be assigned from a single thread. For this reason even > peak load on coordinator should not consume too much resources. I think we > can assign coordinators automatically in first iteration.
For me need of dedicated coordinator nodes is clear: each mvcc transaction/query will wait for mvcc coordinator response, if coordinator will also process cache operations/compute jobs then any user code executed on coordinator and consuming lot of CPU/heap will slowdown ALL mvcc transactions/queries. As a user I want to make sure that coordinator node will process only internal requests related to mvcc. Also why do you think that all numbers should be assigned from single thread? Thanks On Mon, Sep 18, 2017 at 2:59 PM, Semyon Boikov <[email protected]> wrote: > Nikolay, thanks for comments > > > > How will Ignite handle "mvcc coordinator" fail? > > What will happen with if coordinator fails in the middle of a > transaction? > > Could tx be committed or rollbacked? > > I think coordinator failure will be handled in the same way as failure of > one of transaction's 'primary' node: if coordinator fails during 'prepare' > phase then tx is rolledback. > > >> Will we have some user notification if coordinator becomes slower? > > Now in Ignite we do not have common notion of 'user notification's, but we > can add some metrics for coordinator performance on public API. > > Thanks > > > On Mon, Sep 18, 2017 at 1:01 PM, Николай Ижиков <[email protected]> > wrote: > >> Hello, Semyon! >> >> > It seems we need introduce special 'dedicated mvcc coordinator' node >> role >> >> How will Ignite handle "mvcc coordinator" fail? >> >> What will happen with if coordinator fails in the middle of a transaction? >> Could tx be committed or rollbacked? >> >> Will we have some user notification if coordinator becomes slower? >> >> > IgniteConfiguration.isMvccCoordinator >> >> flag name seems OK. >> >> >> 2017-09-18 12:39 GMT+03:00 Semyon Boikov <[email protected]>: >> >> > Hi all, >> > >> > Currently I'm working on MVCC feature (IGNITE-3478) and need your >> opinion >> > on related configuration options. >> > >> > 1. MVCC will definitely bring some performance overhead, so I think it >> > should not be enabled by default, I'm going to add special flag on cache >> > configuration: CacheConfiguration.isMvccEnabled. >> > >> > 2. In current mvcc architecture there should be some node in cluster >> > assigning versions for tx updates and queries (mvcc coordinator). Mvcc >> > coordinator is crucial component and it should perform as fast as >> possible. >> > It seems we need introduce special 'dedicated mvcc coordinator' node >> role: >> > it should not be possible to start cache on such node and it should not >> > process user's compute jobs. At the same time it should be possible that >> > any regular server node can become mvcc coordinator: this can be useful >> > during development (no extra setup for mvcc will be needed), or support >> > scenario when all dedicated coordinator nodes fail. So we need a way to >> > make node a 'dedicated mvcc coordinator', we can add special flag on >> ignite >> > configuration: IgniteConfiguration.isMvccCoordinator. >> > >> > What do you think? >> > >> > Thanks >> > >> >> >> >> -- >> Nikolay Izhikov >> [email protected] >> > >
