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: http://blog.alexyakunin.com/2010/08/con ... 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?

Yes.

> 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.