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
|
Hello, We are using Mindscape in developing an application (VisualStudio 2008, Sql server) We have static class with the static member for creating LightSpeedContext. And in data layer(having different classes), we are using this static instance of LightSpeedContext. Everything works fine. But the problem we are planning to use same application for different clients (Has different databases). During login we will decide the connection string based on client id present in query string. I think in this case, static member for Lighspeedcontext mayn't work. Could you please help in resolving this issue with a small example. Thanks in Advance AV |
|
|
|
|
Yes, you wouldn't want to use a static context where you are switching out the connection string based on the tenant, rather you will want to initialise the context on demand, presumably this will be on a per request basis - have a read of this thread where the same problem has been discussed: http://www.mindscapehq.com/forums/thread/445166 - let us know if you have any additional questions though :)
|
|
|
|
|
Hi Jermy, Thanks for your reply. I saw the post reg the same issue. Instaed of creating context per request, is it possible to create one context per tenant and save all those contexts somehow in the application. So, when user logins in, based on tenant Id, if the context is already present it will use the same, if not it creates new instance. If we do in this way will there be any problem with the key numbers. Thanks, Anu |
|
|
|
|
Hi Anu, You could either cache these instances say in the application cache, or just have a static dictionary which you are dealing with depending on what would be the best fit for your application. Its worth noting though that the context is lightweight and represents the configuration for creating a UnitOfWork (e.g. what provider should I use and what is the connection string for connecting to the database) so creating these on demand is going to be a bad thing. In regards to your concern about key numbers are you referring to allocations from the KeyTable for your entity Id's? You should not see any issues with this regardless of concurrency and also the context is not the entity which manages this, rather it is something which is managed within each UnitOfWork.
|
|
|
|
