Yes, that you a lot
On Tue, Sep 8, 2015 at 5:25 PM, Tyler Hobbs wrote:
>
> On Sat, Sep 5, 2015 at 8:32 AM, ibrahim El-sanosi <
> ibrahimsaba...@gmail.com> wrote:
>
>> So in this scenario, the latest data that wrote to the replicas is [K1,
>> V2] which should be the
er, in practice this is a very rare valid use case as
> clusters doing several hundred thousand transactions per second (not
> uncommon) would find that "last timestamp" is hopelessly wrong every time
> to at best be an approximation, no matter the database technology.
>
>
""It you need strong consistency and don't mind lower transaction rate,
you're better off with base""
I wish you can explain more how this statment relate to the my post?
Regards,
here are no vector clocks to allow you to manage
> the conflict on your own at this point.
>
>
> From: ibrahim El-sanosi
> Reply-To: "user@cassandra.apache.org"
> Date: Sunday, September 6, 2015 at 11:28 AM
>
> To: "user@cassandra.apache.org"
> S
:57 PM, Jeff Jirsa
wrote:
> In the cases where NTP and client timestamps with microsecond resolution
> is insufficient, LWT “IF EXISTS, IF NOT EXISTS” is generally used.
>
>
> From: ibrahim El-sanosi
> Reply-To: "user@cassandra.apache.org"
> Date: Sunday, September
t;clocks should be synchronized", it includes
> Cassandra nodes AND clients
>
> NTP is the way to go
>
> Le 6 sept. 2015 à 14:56, Laing, Michael a
> écrit :
>
> https://en.wikipedia.org/wiki/Network_Time_Protocol
>
> On Sun, Sep 6, 2015 at 8:23 AM, ibrahim El
o, or could you refer me to any related article?
>
> Thank you
>
>
> Ibrahim
>
> On Sun, Sep 6, 2015 at 1:00 PM, Laing, Michael
> wrote:
>
> I think I saw this before.
>
> Clocks must be synchronized.
>
> On Sun, Sep 6, 2015 at 7:28 AM, ibrahim El-sanosi <
&g
gt; On Sun, Sep 6, 2015 at 7:28 AM, ibrahim El-sanosi <
> ibrahimsaba...@gmail.com> wrote:
>
>> Hi folks,
>>
>> Assume we have 4-nodes cluster N1, N2, N3, and N4 and replication factor
>> is 3. When write CL =ALL and read CL=ONE:
>>
>> Client
Hi folks,
Assume we have 4-nodes cluster N1, N2, N3, and N4 and replication factor is
3. When write CL =ALL and read CL=ONE:
Client c1 sends W1 = [k1,V1] to N1 (a coordinator). A coordinator (N1)
generates timestamp Mon 05-09-2015 11:30:40,200 (according to its local
clock) and assigned it to W
In this cases, assume we have 4-nodes cluster N1, N2, N3, and N4 and
replication factor is 3. Client c1 sends W1 = [k1,V1] to N1 (a
coordinator). A coordinator (N1) generates timestamp Mon 05-09-2015
11:30:40,200 (according to its local clock) and assigned it to W1 and sends
the W1 to the N2, N3,
linykh
>> wrote:
>>
>>> Your application.
>>>
>>> On Fri, Sep 4, 2015 at 10:26 AM, ibrahim El-sanosi <
>>> ibrahimsaba...@gmail.com> wrote:
>>>
>>>> Dear folks,
>>>>
>>>> When we hear about the notion
Ok, why coordinator does generate timesamp, as the write is a part of
Cassandra process after client submit the request to Cassandra?
On Fri, Sep 4, 2015 at 6:29 PM, Andrey Ilinykh wrote:
> Your application.
>
> On Fri, Sep 4, 2015 at 10:26 AM, ibrahim El-sanosi <
> ibrahimsa
Dear folks,
When we hear about the notion of Last-Write-Wins in Cassandra according to
timestamp, *who does generate this timestamp during the write, coordinator
or each individual replica in which the write is going to be stored?*
*Regards,*
*Ibrahim*
you.
Regards,
Ibrahim
On Wed, Aug 26, 2015 at 12:19 PM, ibrahim El-sanosi <
ibrahimsaba...@gmail.com> wrote:
> Thank you lot
>
> Ibrahim
>
> On Wed, Aug 26, 2015 at 12:15 PM, Sylvain Lebresne
> wrote:
>
>> Yes
>>
>> On Wed, Aug 26, 2015 a
Thank you lot
Ibrahim
On Wed, Aug 26, 2015 at 12:15 PM, Sylvain Lebresne
wrote:
> Yes
>
> On Wed, Aug 26, 2015 at 1:05 PM, ibrahim El-sanosi <
> ibrahimsaba...@gmail.com> wrote:
>
>> OK. I see what the purpose of acknowledgment round here. So
>> acknow
AM, Sylvain Lebresne
wrote:
> On Wed, Aug 26, 2015 at 12:19 PM, ibrahim El-sanosi <
> ibrahimsaba...@gmail.com> wrote:
>
>> Yes, Sylvain, your answer makes more sense. The phase is in Paxos
>> protocol sometimes called learning or decide phase, BUT this phase does not
&
Yes, Sylvain, your answer makes more sense. The phase is in Paxos protocol
sometimes called learning or decide phase, BUT this phase does not have
acknowledgment round, just learning or decide message from the proposer to
learners. So why we need acknowledgment round with commit phase in
lightweigh
Hi folks,
To achieve linearizable consistency in Cassandra, there are four
round-trips must be performed:
1. Prepare/promise
2. Read/result
3. Propose/accept
*4. **Commit/acknowledgment *
In the last phase in Paxos protocol (white paper), there is decide phase
only,
What an excellent explanation!!, thank you a lot.
By the way, I do not understand why in lightweight transactions in
Cassandra has round-trip commit/acknowledgment?
For me, I think we can commit the value within phase propose/accept. Do you
agree? If not agree can you explain why we need commit/a
is, N1 will restart the whole algorithm with a new ballot).
>
>
> On Tue, Aug 25, 2015 at 1:54 PM, ibrahim El-sanosi <
> ibrahimsaba...@gmail.com> wrote:
>
>> Hi folks,
>>
>>
>> Cassandra provides *linearizable consistency (CAS, Compare-and-Set) by
>&g
Hi folks,
Cassandra provides *linearizable consistency (CAS, Compare-and-Set) by
using Paxos 4 round-trips as following*
*1. **Prepare/promise*
*2. **Read/result*
*3. **Propose/accept*
*4. **Commit/acknowledgment *
Assume we have an application for resistering new account
Dear folks,
I have doubt on how Cassandra performs a write request; I have two
scenarios, please read them and ensure which one is correct?
Assume we have cluster consists of 4 nodes N1, N2, N3, and N4. As Cassandra
distributes the nodes in ring topology, the nodes links as following:
N-->N-->
22 matches
Mail list logo
