This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi: I've been evaluating Lightspeed for the last week to use with my APS.NET/MySQL website development. The evaluation went well and I bought a developer license today. Everything is working as expected but I have a question about the indentityBlockSize to ask the experts. Currently I am creating a new context for every database transaction I perform. I do this because there is no way (that I know of) to allocate it globally so all pages can use it. I suppose creating a base Page class that contains a static variable might work. Anyways, the nature of my database operations causes identities to be wasted if I use the default 10 for the indentityBlockSize. I have set it lower and everything still work. Just wondering if this is the best approach for this type of application? It is not a high volume website so performance isn't too critical but at the same time I don't want to bog it down unnecessarily.
Thanks. |
|
|
A LightSpeedContext is generally a static chunk of configuration information, so we usually do recommend allocating it globally -- there's no value in creating a new LightSpeedContext for every page because they'll all contain exactly the same info. You can do this in Global.asax.cs or in a custom class file: public class Global { Then in your pages you create units of work from this global context: using (MyUnitOfWork uow = Global.Context.CreateUnitOfWork()) { ... } Yes, it does couple your pages to the Global (or Settings or whatever you call it) class but it's a pretty harmless piece of coupling (in my opinion anyway!). KeyTable allocations are tracked on a per-LightSpeedContext basis so this means that all your pages will be allocating from the same pool, and you will therefore use the keyspace efficiently. (In fact you will only skip keys when the ASP.NET process recycles, as this will result in a new instance of LightSpeedContext getting allocated.) Setting a lower IdentityBlockSize will work, but will result in more KeyTable queries to the database (e.g. every two entities instead of every 10 entities). The shared LightSpeedContext is therefore usually a better solution. |
|
|
That great Ivan, thanks for the help!
Scott |
|
|
Hi Ivan:
I have a couple more questions about the key table
1) When does the context allocate a block of keys? When it is created or when a insert record is requested? 2) The default key size is an int. If one wanted more key space, would you just change all of the id's including the keytable to bigint? Thanks. |
|
|
1. The context allocates a block of keys from the KeyTable when a new entity is added to a unit of work associated with that context, *and* the previous block if any has run out. Creating a context alone, or indeed creating a unit of work, does NOT result in an allocation from the KeyTable -- it only allocates if an entity is added. 2. Yes. Internally LightSpeed uses longs, so it will happily cope with a bigint KeyTable and long IDs. |
|