TSynUniqueIdentifierGenerator - WOW

mpv · 2016-02-05 09:49:12

I take a look at new TSynUniqueIdentifierGenerator. This is exactly how my ID generation algorithm is work (I currently use database sequences, but your class will allow me to use DB what do not have sequences support).
But I have a suggestion - let's split Identifier onto two part: clientID (for example first 12 bit) - the identifier of client & instanceID (4 bit) - the identifier of node unique within client (in case I have several server instances)

This will allow to unique identify clients (for example to resolve replication conflicts).
P.S.
I understand what I can generate Identifier in my part of software using rule I describe (clientID and instanceID) but code become much clean if this will be implemented in the TSynUniqueIdentifierGenerator as a two different properties..

ab · 2016-02-05 10:02:17

I do not understand exactly what a "clientID" and "instanceID" are, in your terms.
What do you call a "node" within a client?

mpv · 2016-02-05 13:23:16

For example, I wrote govService.exe application server, and it uses an Oracle database. Clients (browser, for example) doesn't meter here.

For customer "Company 1" with 100 employee I run a single instance of govService.exe (this is small organization) and assign clientID = 1 (Company 1) & instanceID = 0 (in the application config)

For customer "Company 2" with 10000 employee I run two instance of a govService.exe(with a hardware load balance) but both will use the same Oracle database. In this case I assign clientID = 2 (Company 2) & instanceID = 0 for first instance & instanceID = 1 for second.

Some data stored in Company1 & company2 database are the subject of replication to the Company3 database.

As a result:
- during replication or even looking on the record ID I always know customer, who generate an ID.
- different govService.exe instances what use the same RDBMS will produce different identifiers

And sorry for my English..

Last edited by mpv (2016-02-05 13:26:00)

mpv · 2016-08-08 12:50:37

We discover a problem in TSynUniqueIdentifierGenerator - in some cases it will generate a duplicate keys.
My use-case:
service got the "reload" command and recreate it internals, including TSynUniqueIdentifierGenerator instances. Because the processID is not changed, new instance of TSynUniqueIdentifierGenerator sometimes generate the same ID as previous.

Possible solution is to change time resolution in TSynUniqueIdentifierGenerator.ComputeNew

//  instead of
currentTime := DateTimeToUnixTime(NowUTC);
// do
currentTime := (DateTimeToUnixMSTime(NowUTC) shr 8) and Int64($FFFFFFFF);

In this case we lost a century, but I can sleep(100) between instance recreation instead on sleep(1000) - 1 second is too much for me.

ab · 2016-08-08 15:54:56

This would break a lot of existing code, since it would change the date format used in the TSynUniqueIdentifier field...
So I'm afraid it is too late for such a breaking change.

Isn't it possible to keep the TSynUniqueIdentifierGenerator instances at restart, or at least re-use the previous counter?

mpv · 2016-08-08 16:53:32

In fact I copy-paste your realization, because I need to change a internal layout to be a 52bit (for JavaScript clients), so changes to mORMot is not necessary. I understand your regression problem. May be just add a note to docs to prevent others from such problems..

mORMot Open Source

#1 2016-02-05 09:49:12

TSynUniqueIdentifierGenerator - WOW

#2 2016-02-05 10:02:17

Re: TSynUniqueIdentifierGenerator - WOW

#3 2016-02-05 13:23:16

Re: TSynUniqueIdentifierGenerator - WOW

#4 2016-08-08 12:50:37

Re: TSynUniqueIdentifierGenerator - WOW

#5 2016-08-08 15:54:56

Re: TSynUniqueIdentifierGenerator - WOW

#6 2016-08-08 16:53:32

Re: TSynUniqueIdentifierGenerator - WOW

Board footer