How does the built in ID generation works? When I create a new entity in a new transaction scope, the new ID will leave a huge gap from the last entity ID (skipping 100+ integer values). Why is it designed in this way? I expect it to behave like SQL Server identity column but it is not.


Updated at 03.04.2010 4:21:27

The gap was in fact caused by hierarchy root inheritance. I modified my model a bit and test again.

The ID is incremental by 1 when creating entity with the same transaction scope and different sessions.

But, it is leaving a gap if each time I call Domain.Build()

The small gaps are not a big concern in ASP.net app.

However, if I use DO in WPF client-server architecture, then each user will be using different Domain, since the key is client-side generated, how DO make sure it won't duplicate IDs in this scenario??

Also, I notice DO creates a [Int64-Generator] table in my database, but the table is empty, where is the key info being stored?

This thread was imported from our support forum. The original discussion may contain more detailed answer. Original topic by ccchai.

asked Apr 02 '10 at 10:14

Editor's gravatar image

Editor
46156156157


One Answer:

It really isn't: default key generators use HiLo algorithm to generate the identities faster.

See Keys section in Manual, as far as I remember, it explains this.

The gap you see each time, likely, happens because Domain is re-created before each subsequent attempt to generate a key. Otherwise there should be no gaps.


**> However, if I use DO in WPF client-server architecture, then each user will be using different Domain, since the key is client-side generated, how DO make sure it won't duplicate IDs in this scenario??

Also, I notice DO creates a [Int64-Generator] table in my database, but the table is empty, where is the key info being stored?**

[Xxx-Generator] table has autoincrement column with increment value equal to key generator cache size (set in DomainConfiguration, 128 by default).

When a particular key generator needs to preserve a bulk of keys for future distribution, it executes an insertion to this table, gets newly generated ID and then rollbacks a transaction. So this table is always empty, athlough autoincrememnt sequence is anyway maintained for it (it's logical that rollback doesn't affect on the seed value of autoincrement columns).

So there will be no issues in case when multiple Domains are connected to the same database (e.g. in WPF case): each of key generators in these Domains will get its own bulk of keys for distribution.

Finally, it's worth to mention that such bulk of keys are "preserved" in background: when KeyGenerator (actually - CachingKeyGenerator) distributes 50% of keys, it issues assynchronous (non-blocking) request for the next bulk of keys (this request uses dedicated Session & connection). When this request gets completed, the next set of keys is queued for future distribution. Key generation gets temporarily blocked only when there are no more keys for distribution, and asynchronous bulk key allocation request isn't completed yet.

answered Apr 02 '10 at 12:11

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×574

Asked: Apr 02 '10 at 10:14

Seen: 2,685 times

Last updated: Apr 02 '10 at 10:14

powered by OSQA