servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: [DISCUSS] TCC scanner design
Date Thu, 11 Oct 2018 22:34:50 GMT
It could be more convenient that Omega can know the Alpha address dynamically.
We could leverage zookeeper , consul or service center to help us
manage the Alpha instances information.

BTW, if the transaction is started in certain kind of Alpha, we can
just leave the transaction there. If the Alpha server is down, the
other alive Alpha should take care of it.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Sep 29, 2018 at 2:00 PM 赵俊 <zhaojun12@jd.com> wrote:
>
> Yeah, this is often implemented by some coordinator like zookeeper etc.
> If we know the total count and index location of every alpha, the shading policy is very
easy.
>
> > On 29 Sep 2018, at 1:17 PM, Willem Jiang <willem.jiang@gmail.com> wrote:
> >
> > We may introduce some shading policy to let the Alpha instance to hold
> > a certain kind of global transactions.
> > If there is something wrong with the instance, the other Alpha may
> > take the control of the global transactions which is loaded from DB.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Sep 28, 2018 at 9:42 PM cherrylzhao <zhaojunv3@126.com> wrote:
> >>
> >> Hi, all
> >>
> >> In order to find timeout global transaction, we need a scanner to handle the
global transaction.
> >> If scanner was started as same logic within many alpha, it will cause concurrent
access with same db record.
> >> So it seem that we need a registration to manage the alpha machine,
> >> then we can design some data sharding logic to make a global traction will only
be handle by one alpha.
> >>
> >> Any thought?
>

Mime
View raw message