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
|
I am starting to use LS in some server archietcture and need to understand if LS will cache Contexts as well as underlying connection information efficently. Our custom OR layer now does this agressively on top of ADO.Net since allocating DB connections is costly. We also agressively cache configuration information.
So, what happens in LS given this Server Call: public Response Retrieve(string p1) { var context = new LightSpeedContext<MyUow>("MyDatabase"); MyUow uow = context.CreateUnitOfWork();} Does LS cache the settings for MyDatabase? Also, is the CreateUnitOfWork effciently handled? I can build framework to deal with this, I was just hoping LS handled it. -Scott
|
|
|
In your example code, LightSpeed would instantiate a new LightSpeedContext, and populate it from the app.config / web.config file (which would be cached by .NET). If you don't want this to happen, create the LightSpeedContext at global level (or via an IoC container or whatever your preferred strategy is). LightSpeedContext is purely a holder of configuration information so a server architecture can safely spin multiple units of work off the same context. (However the UOW *does* hold a reference back to the context, so you must be careful not to modify context settings as this will affect all UOWs.) The LightSpeedContext object caches all the settings it needs -- for example the connection string is copied to a member variable, it is not retrieved from config each time it is required. Similarly, the second line of your example creates a new UnitOfWork object. This has a new identity map, will eventually acquire a new database connection (though these can of course take advantage of .NET connection pooling), etc. UOWs are *not* pooled: CreateUnitOfWork does exactly what it says on the tin. The actual creation of the UOW should be pretty rapid as the constructor just news up a few member variables, but the UOW does hold potentially expensive resources (a database connection, an identity map which can grow over time, etc.). If your concern is connection allocation efficiency, we may need to explore the details with you: we do not expose a means for you to inject a custom allocation strategy; and reusing units of work would reuse their connections, and is possible but requires care. Hope this answers your questions -- please follow up if it doesn't! |
|