Am 01.08.2013 um 16:04 schrieb Ian McMahon <[email protected]>:
> Perhaps a GUID mechanism that hashes machine info and system clock. If > multiple systems are involved, the system clocks need to be synchronized for > ordering. The requirement IMO are: no acks may be lost; serials must be ordered until proven otherwise; and producers must be able to tell 'their acks' from 'other acks'. If the ordering is relevant, then only in the relation of a producer and related acknowledgements, not globally; it is irrelevant what other producers are doing as long as the acks can properly directed to producers and are not lost. This is why the originatorID/serial tuple is the simplest way to achieve that, without random numbers and collision potential, clock synchronisation and all that. If this isnt enough to turn you off for good, read a bit about "clock synchronization and total ordering of events in distributed systems", and congratulations for achieving tenure after a decade or so;) -- gents - this is going off on a tangent, this isnt algorithm conception time just yet. We need a testcase first which reproduces the event sequence as reported, and where repair strategies can be tested against. This might involve some C and some threads. Who can take that on? -m > On Aug 1, 2013, at 10:00 AM, Michael Haberler <[email protected]> wrote: > >> >> Am 01.08.2013 um 15:50 schrieb EBo <[email protected]>: >> >>> On Aug 1 2013 7:45 AM, Dave wrote: >>>> On 8/1/2013 7:53 AM, Michael Haberler wrote: >>>>> I rule out an RPC server for retrieving a globally-unique serial, >>>>> this doesnt scale. >>>>> >>>> >>>> Use a random 32 bit number? >>> >>> I know that there are lots of systems that have to deal with this kind >>> of thing. Does anyone know what published algorithms solve these >>> issues? >> >> before choosing an algorithm we need to determine if a total ordering of >> serials is needed. >> >> I would say yes, in particular if several commands might be outstanding if a >> queue is involved >> >> -m >> ------------------------------------------------------------------------------ >> Get your SQL database under version control now! >> Version control is standard for application code, but databases havent >> caught up. So what steps can you take to put your SQL databases under >> version control? Why should you start doing it? Read more to find out. >> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
