Jim,

Thanks for the explanation !

Let's see if I got it right :-)

Jim Starkey wrote:

>Netfrastructure computes sequences as "physicalSequence * interval +
>cpuId" where "interval" is defined on a per-schema value and "cpuId" is
>set at database initialization based on mac id or ip address. "CpuId",
>of course, must be less than "intervalId". There are a couple of extra
>rules enforced by the system:
>
>

This looks like very similar to what I called stepped values. but are
more flexible since one can change the parameters for the gap on the fly.

I will try to show how I understand your post, so you could correct me
what I didn't get right.

Let's suppose I define the interval as 1000, the cpuId will vary for each DB from 0 to 999, computed in some way by Netfrastructure framework so that each one know how to get a number without coliding with the others, don't know how you did it. Let's assume it justs work, don't mind how....

First DB (cpuId = 0) has a physical sequence that starts with value 1, so virtual sequences will be:
1 * 1000 + 0 = 1000
2 * 1000 + 0 = 2000
...
10 * 1000 + 0 = 10000
11 * 1000 + 0 = 11000
after interval expand to 10000
12 * 10000 + 0 = 120000

Second DB (cpuID = 1) has a physical sequence that starts with value 1, so virtual sequences will be:
1 * 1000 + 1 = 1001
2 * 1000 + 1 = 2001
...
10 * 1000 + 1 = 10001
11 * 1000 + 1 = 11001
after interval expand
12 * 10000 + 1 = 120001

....

Tenth DB (cpuID = 10) has a physical sequence that starts with value 1, so virtual sequences will be:
1 * 1000 + 10 = 1010
2 * 1000 + 10 = 2010
...
10 * 1000 + 10 = 10010
11 * 1000 + 10 = 11010
after interval expand
12 * 10000 + 1 = 120010

so far so good.

Then I though, hummm 1000 for interval is just to small let's expand it to 10000.

Thousandth DB (cpuID = 1000) has a physical sequence that starts with value 1, so virtual sequences will be:
1 * 10000 + 1000 = 11000 (colides with virtual sequence for physical sequence 11 on cpuId 0 when interval = 1000)
2 * 10000 + 1000 = 21000 (colides with virtual sequence for physical sequence 21 on cpuId 0 when interval = 1000)
...
10 * 10000 + 1000 = 101000 (colides with virtual sequence for physical sequence 101 on cpuId 0 when interval = 1000)

Thousand First DB (cpuID = 1001) has a physical sequence that starts with value 1, so virtual sequences will be:
1 * 10000 + 1001 = 11001 (colides with virtual sequence for physical sequence 11 on cpuId 1 when interval = 1000)
2 * 10000 + 1001 = 21001 (colides with virtual sequence for physical sequence 21 on cpuId 1 when interval = 1000)
...
10 * 10000 + 1001 = 101001 (colides with virtual sequence for physical sequence 101 on cpuId 1 when interval = 1000)

If this works this way, I think we will get duplicated values, I think I've missed something here :-(

Did you manage to enforce a starting physical sequence value when a new DB is created based uppon the interval value or the max sequence values of all others DB's ?

The starting physical value is human defined on db creation ?

> 1. A physical sequence can be set forward only, never back.
>
>

ok

> 2. The interval can be increased, never decreased.
>
>

ok, but see above.
The interval should be increased on every DB at same time right ? How it
is done ?

> 3. Back and restore handle physical, not virtual, sequences
>
>
>

ok

>These rules guarantee that sequence values are always monotonically
>increasing and are unique cluster wide. There is no need to reserve cpu
>id, although it doesn't hurt if you do, since the interval can be safely
>increased at any point.
>
>
>
>The specific rules that map mac address or ip number to cpu id are
>application specific and are implemented in the class initializer for a
>schema's Java class. Since Firebird has either schemas nor Java,
>another scheme would be required.
>
>

This is a point I didn't understand how do you get an unique ID based on
MAC or IP Address for unconnected DB's that is guaranteed unique, it's
made with human intervention ?

>>If this ensure a unique value accross multiple unconnect DB's, I will
>>agree that we don't need anything else.
>>
>>
>It works like a champ.
>
>

Thanks for the explanation, I am curious to see what I have missed, this
looks like a very simple and elegant way to generate unique ID's without
the fixed interval limits of what I called "stepped values".

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.5 - Release Date: 29/03/2005