Locking with Linq to SQL’s deferred execution
April 22nd, 2009 . by Daniel HölblingIf you have been reading this blog lately you may have noticed that I’m currently working on a project where I chose Linq to Sql as my data-source, inspired by the IQueryable<T> Repository Rob Conery introduced in his MVC Storefront series.
The basic idea of the IQueryable<T> repository is to have the repository return a IQueryable list of C# domain objects that can then be filtered, queried, parsed at higher layers of the application.
So things like paging, filtering etc (all business concerns) can be applied to the query at a later stage instead of having to propagate all of these requirements down to the Repository (Ayende wrote something great on the death of Repository you should check out).
So my business code would call the repository for all objects and then apply logic to it:
var preferredUsers = repository.GetAll() .Where(p => p.JoinDate < DateTime.Now.AddYears(-1)) .Skip(PAGE_SIZE*pageNumber) .Take(PAGE_SIZE);
I loved it. Not having to propagate concerns like paging and filtering to the DAL was awesome, and since the interface is so damn simple I very quickly came up with decorators that did error handling, caching and logging at the DAL level.
Since I’ve become a dependency injection nut, I then came up with a injectable datacontext so my repositories don’t have anything to do with the data context creation (thus sparing me the configuration concerns in that class).
My concrete repository implementation then looked like this:
public class UserRepository : IRepository<BlogUser>
{
private DataClassesDataContext context;
public UserRepository(DataClassesDataContext context)
{
this.context = context;
}
public IQueryable<BlogUser> GetAll()
{
return from u in context.Users
select new BlogUser
{
Id = u.Id,
Username = u.Name,
Password = u.Password
};
}
}
You see, the context gets injected and besides the query there is nothing in the repository, SRP .. check.
Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.
And this is where it blew up in my face, having multiple threads access the repository leads to some nasty race conditions for the datacontext, and I found no sane way of dealing with this at the DAL level.
Try this:
public static void main()
{
var repository = new UserRepository(new DataClassesDataContext());
new Thread(() => ThreadStart(repository)).Start();
new Thread(() => ThreadStart(repository)).Start();
}
public static void ThreadStart(IRepository<BlogUser> repository)
{
const int PAGE_SIZE = 10;
int pageNumber = 1;
var preferredUsers =
repository.GetAll()
.Where(p => p.JoinDate < DateTime.Now.AddYears(-1))
.Skip(PAGE_SIZE*pageNumber)
.Take(PAGE_SIZE);
preferredUsers.ToList();
}
The same query as before, but two threads that share the same repository, therefore sharing the same datacontext. Once started, the whole thing will blow up with a InvalidOperationException stating that the connection is closed.
I didn’t bother to go into the DataContext source and check out why they are closing the connection, but apparently after the query is executed it takes some time for the context to “recover” and be able to accept a new query.
I immediately tried to solve the problem by adding a lock on the datacontext in the repository class (since the contexts are pooled, it was the only thing that made sense since I don’t need to lock all connections, just the one I’m currently using).
public IQueryable<BlogUser> GetAll()
{
lock (context)
{
return from u in context.Users
select new BlogUser
{
Id = u.Id,
Username = u.Name,
Password = u.Password
};
}
}
I intentionally said I tried, because it didn’t work. The lock gets executed alright, but the query isn’t run inside the lock{} but rather at the calling code, in my business class (the power of deferred execution). So the only way to prevent a race condition for my datacontext would have been to add locking to the business code:
const int PAGE_SIZE = 10;
int pageNumber = 1;
var preferredUsers =
repository.GetAll()
.Where(p => p.JoinDate < DateTime.Now.AddYears(-1))
.Skip(PAGE_SIZE*pageNumber)
.Take(PAGE_SIZE);
lock(repository)
{
preferredUsers.ToList();
}
Omg right? So, besides the fact that I can’t guarantee that two repositories don’t use the same datacontext (and therefore racing against each other), I just opened the Pandora’s box of possible errors (give me a month and I’ll forget the locking at least 3 times).
Also, it’s just painful to see an implementation detail of the data access layer leak into the business code for no apparent reason.
And the only way I found on how to solve that problem was to supply a new datacontext to every query, so I get rid of the whole locking. I did so by injecting a datacontext factory into the repository and call the factory every time I execute a query.
This fixed the issue for now, but I don’t feel too good about the solution. Creating new datacontext object for every query somehow feels wrong, and I’d love to hear suggestions from you on how to change that.
i think you work really hard for this. This are really cool. Thanks for sharing this information.
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Daniel,rnrnI read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/, and assumed you would’ve implemented you UserRepository differently using Windsor.rnrnI don’t follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would’ve assumed your repository constructor would’ve created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis. rnrn# public UserRepository() rn# { rn# this.context = container.Resolve();rn# } rnrnThis way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn’t have multiple threads attempting to use the same context.rnrnIf you were using your Repository as a singleton I don’t know how you could possibly get methods like these to work with your context:rnrnrn //Insert/Deletern public void Add( BlogUser user) {rn context.Users.InsertOnSubmit( user);rn }rnrn public void Delete( BlogUser user) {rn context.Users.DeleteOnSubmit( user);rn }rnrn //Persistencern public void Save() rn {rn context.SubmitChanges();rn }rn
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Hi Chuck, thanks for your comment.rnrnYou raise a valid point here. rnI should have noted that I don’t have ANY persistency story because this whole architecture is only for reading objects. rnIt’s purely for displaying data, I don’t have write access to the database at all. So for me the #1 priority was to read fast.rnrnIt made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:rnhttp://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/ (yes, just recently, had some NDA issues before).rnrnSo anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. rnrnSorry for the confusion. rngreetings Daniel
Daniel,
I read your original post for InjectableDataContext, http://www.tigraine.at/2009/04/10/how-to-make-a..., and assumed you would've implemented you UserRepository differently using Windsor.
I don't follow this logic, “Now, the logical thing to do in my IoC configuration was to have the repositories be singletons, and so every repository has one datacontext attached to it.” Why would you want your repositories to be singletons? DataContext is not designed to be used concurrently by multiple threads. I would've assumed your repository constructor would've created the DataClassesDataContext instance (or the InjectableDataContext instance) via the Windsor container. This should allow you to set the windsor component lifestyle to Transient, which would cause a new instance of DataClassesDataContext to be created on a per request basis.
# public UserRepository()
# {
# this.context = container.Resolve<DataClassesDataContext>();
# }
This way you could still use all of the CRUD/Transaction niceness of LinqToSql because each Repository would run with its own context and you wouldn't have multiple threads attempting to use the same context.
If you were using your Repository as a singleton I don't know how you could possibly get methods like these to work with your context:
//Insert/Delete
public void Add( BlogUser user) {
context.Users.InsertOnSubmit( user);
}
public void Delete( BlogUser user) {
context.Users.DeleteOnSubmit( user);
}
//Persistence
public void Save()
{
context.SubmitChanges();
}
Hi Chuck, thanks for your comment.
You raise a valid point here.
I should have noted that I don't have ANY persistency story because this whole architecture is only for reading objects.
It's purely for displaying data, I don't have write access to the database at all. So for me the #1 priority was to read fast.
It made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:
http://www.tigraine.at/2009/05/12/kaerntenat-ca... (yes, just recently, had some NDA issues before).
So anyway there will only be one initialization of the repository since the cache holds only one reference to the repository.
Sorry for the confusion.
greetings Daniel