[erlang-questions] Does erlang:now() guarantee that subsequent calls to this BIF returns continuously increasing values even in erlang cluster?

[Michael Turner]

If you can make do with a partial order rather than a total order, somehow:

   http://www.erlang.org/doc/man/seq_trace.html

Basically, Lamport clocks.

  http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf



Regards,
Michael Turner
Executive Director
Project Persephone
K-1 bldg 3F
7-2-6 Nishishinjuku
Shinjuku-ku Tokyo 160-0023
Tel: +81 (3) 6890-1140
Fax: +81 (3) 6890-1158
Mobile: +81 (90) 5203-8682
turner@REDACTED
http://www.projectpersephone.org/

"Love does not consist in gazing at each other, but in looking outward
together in the same direction." -- Antoine de Saint-Exupéry

On Mon, Apr 20, 2015 at 9:54 PM, Fred Hebert <mononcqc@REDACTED> wrote:

> On 04/20, Daniel wrote:
>
>> I am looking for a global sequence generator in erlang cluster.
>>
>> I think erlang:now() is promising, because it is fast enough and “also
>> guarantees that subsequent calls to this BIF returns continuously
>> increasing values”. But I am not quite sure whether this guarantee also
>> works for erlang cluster which have several nodes running on different
>> servers?
>>
>> I have read Time and time correction in Erlang (
>> http://www.erlang.org/doc/apps/erts/time_correction.html), but still
>> have no conclusion.
>>
>>
> There is a very important thing. You did mention *in a cluster*. What you
> are asking for, a "global sequence" requires putting every call you have
> into a well-known order where any value can be compared to any value and
> sorted properly. This is known as a "total order", and requires
> synchronization.
>
> This means that doing this requires your nodes to discuss together, and in
> concert either:
>
> a) elect a leader to create the sequence values
> b) come to an agreement for the sequence of values
>
> These are very broad lines (the theoretical aspect of it gets mixed in
> with a lot of fancy consistency model in distributed systems talk).
>
> You will want this [generally costly] mechanism when:
>
> - You need an absolute order in the sequence of your events
> - You are ready to see potential unavailability when all the nodes in  the
> system cannot agree on how to allocate the numbers.
>
> There is no way around it. On the other hand, there are some alternative
> options: you could decide to have only *some* events ordered. This means
> that for some values you could definitely say which comes before or after
> the other, but not for all of them. This is called a 'partial order'.
>
> It's what would happen if I generated logs on two different nodes and kept
> the node identifier in the log. When that happens, I know that logs from A
> are in the right order (I trust their timestamp), but I cannot know if node
> A's 2015/04/20T12:59:23+00:00 comes before node B's
> 2015/04/20T12:59:23+00:00: their respective clocks might be off, drifting,
> or their resolution too low for me to decide.
>
> So therefore, when sorting logs for these two systems, I can decide
> whether one came before or after the others from the same node (as long as
> I used a monotonic clock like erlang:now() to generate the values), but
> cannot reliably sort logs across nodes.
>
> The best answer I can personally give you here is not to tell you how to
> properly generate these numbers, but rather to ask right back about what it
> is you're trying to accomplish, and why do you believe you need these
> numbers for?
>
> If there's a way to get away without the continuously increasing values at
> a global level, this will be much simpler operationally than trying to
> maintain healthy clusters that synchronize and block on every ID you want
> to generate.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150420/a594f22d/attachment.htm>