Dear all, i am using hierachyroot with inheritance schema as ClassTable. when i see my root table,i find values like this:

Id  TypeId
  1 102
  2 102
  3 103
  4 103
129 102 (!)
130 102
131 103
257 102 (!)
258 102
259 103
260 103

I dont understand why after Id = 4 , it starts from 129.. i jsut have three tables with all only 4 rows. domainbuilder creates the four rows again n again on each application start up, it should come from id = 5 ,right, but it is coming from id 129.. i checked other meta tables but no one has consumed those auto generated id... could you please help me to understand this behaviour. there are no object created in between 4 to 129 then y the id is changing...

thanks HAN

Updated at 18.08.2010 12:07:11

sure psulek, that ids will not be rollback. my simple question is how id is getting generated. it has Int64-Generator table which has identity column and it has increment value 128. when i am running the application , key range has been taken which will be 128.,,,i create some 500 records and stop application, now when i run the application again, what wud be the id starting from and how DO knows what id to generate. thats it.

pls clear my doubt. thanks HAN

Updated at 19.08.2010 6:56:27

Thanks Alex, i understand that it will fall into fourth slab i.e 0-128,129-256,257-384,385-512, and so on...hence next time when app runs it will be 513. is it that you are internally checking it that what was the last id generated, based on that check the slab, then generate the new id.

Updated at 23.08.2010 7:57:13

Sorry Alex, but for sure i am missing some small piece of info. when you say that generetor gives you the next id ,how can generator give you next id when it has null mentioned that you insert default value and then rollback transaction,so this table has null value. so how it can give you next id when it has null value.

pls help.

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

asked Aug 15 '10 at 11:11

HannanKhanji's gravatar image


edited Sep 06 '10 at 04:55

Alex%20Yakunin's gravatar image

Alex Yakunin

One Answer:

Alex (Xtensive) wrote:

That's because:

  • By default we allocate key ranges in bulks (128 keys by default); see seed and increment values of IDENTITY column in key generator tables. This allows us to distribute keys much faster, since we shouldn't query DB for each particular key; thus keys are always available when we create an instance of Entity in RAM, i.e. we shouldn't persist them to assign their keys. Moreover, if you'd look into the details, you'll discover we start to allocate next key range in the background, when one half of keys in current key range is distributed, i.e. there the total cost of key assignment is almost zero in our case.

  • Key generators (i.e. their instances) are shared among all the Sessions inside Domain; so key generators are, in fact, bound to Domain objects.

  • Cached key ranges become forgotten, when you close the application, or dispose the Domain. That's why see some gaps in distributed keys.

Increment size (i.e. key generator cache size) is manageable. DomainConfiguration.KeyGeneratorCacheSize controls this, but globally - i.e. it sets default value for all key generators. AFAIK, currently it's impossible to specify it for a particular key generator, but likely, I'll fix this in few days.

Alex (Xtensive) wrote:

That's because we always rollback the transaction inserting new row to this table to get new key range. Are these rows really necessary for you there? ;)

If you'd study the log produced by DO4 with Debug level, you'll see something like this:

  2,57s/T1     Debug Storage.Providers.Sql    Session 'KeyGenerator, #3'. Beginning transaction @ ReadCommitted.
  2,57s/T1     Debug Storage.Providers.Sql    Session 'KeyGenerator, #3'. SQL batch: 
                                              INSERT INTO [dbo].[Int32-Generator] DEFAULT VALUES;
                                              SELECT SCOPE_IDENTITY();
  2,57s/T1     Debug Storage.Providers.Sql    Session 'KeyGenerator, #3'. Rollback transaction.

Btw, there is a nice problem related to full IDENTITY support: ... oblem.html - see if you'd like to torture your brain a bit ;)

psulek wrote:

thanks alex. no i was jsut trying to understand the concept. if you rollback the transaction and you have nothing in the table then how you come to know the next id to be generated.

I'm not MS SQL Server expert but i think that even if you rollback transaction already generated identity ids are not rolled-back and thus each time you make begin tran/new identity insert/rollback tran/ you always generate new identity ids? Am i right, alex?

Alex (Xtensive) wrote:

> Am i right, alex?


> now when i run the application again, what wud be the id starting from and how DO knows what id to generate. thats it.

DO will simply allocate the next bulk of keys by query shown above. Since identity seed value is incremented by 128 each time this happens, if you'll start from Id=1, create exactly 500 entries and will restart the application, the next generated Id will be 513.

answered Aug 17 '10 at 04:55

Alex%20Yakunin's gravatar image

Alex Yakunin

Issue about specifying cache size for a particular key generator: ... ail?id=779

(Aug 17 '10 at 04:55) Alex Yakunin Alex%20Yakunin's gravatar image

hannankhanji wrote: Thanks Alex, its clear to me now. but one thing i need to ask here is my "Int64-Generator" table has always one value and that is null. is it right. shouldnt it have some value , like last id generated or so.

pls advice. Thanks HAN

(Aug 17 '10 at 04:55) Editor Editor's gravatar image

Test comment - I'd like to check e-mail.

(Aug 17 '10 at 13:28) Alex Yakunin Alex%20Yakunin's gravatar image

Generators with non-default increment are supported now. See

(Aug 26 '10 at 17:32) Alex Yakunin Alex%20Yakunin's gravatar image
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

powered by OSQA