[DISCUSS] TCC scanner design

[cherrylzhao <zh...@126.com>]

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?

Re: [DISCUSS] TCC scanner design

[Willem Jiang <wi...@gmail.com>]

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 赵俊 <zh...@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 <wi...@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 <zh...@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?
>

Re: [DISCUSS] TCC scanner design

[赵俊 <zh...@jd.com>]

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 <wi...@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 <zh...@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?

Re: [DISCUSS] TCC scanner design

[Willem Jiang <wi...@gmail.com>]

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 <zh...@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?