<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Locking with Linq to SQL&#8217;s deferred execution</title>
	<atom:link href="http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/</link>
	<description>Daniel Hoelbling talks about .NET</description>
	<lastBuildDate>Tue, 16 Feb 2010 17:22:27 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tigraine</title>
		<link>http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/comment-page-1/#comment-2502</link>
		<dc:creator>Tigraine</dc:creator>
		<pubDate>Sat, 16 May 2009 02:22:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/#comment-2502</guid>
		<description>Hi Chuck, thanks for your comment.&lt;br&gt;&lt;br&gt;You raise a valid point here. &lt;br&gt;I should have noted that I don&#039;t have ANY persistency story because this whole architecture is only for reading objects. &lt;br&gt;It&#039;s purely for displaying data, I don&#039;t have write access to the database at all. So for me the #1 priority was to read fast.&lt;br&gt;&lt;br&gt;It made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:&lt;br&gt;&lt;a href=&quot;http://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/&quot; rel=&quot;nofollow&quot;&gt;http://www.tigraine.at/2009/05/12/kaerntenat-ca...&lt;/a&gt; (yes, just recently, had some NDA issues before).&lt;br&gt;&lt;br&gt;So anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. &lt;br&gt;&lt;br&gt;Sorry for the confusion. &lt;br&gt;greetings Daniel</description>
		<content:encoded><![CDATA[<p>Hi Chuck, thanks for your comment.</p>
<p>You raise a valid point here. <br />I should have noted that I don&#39;t have ANY persistency story because this whole architecture is only for reading objects. <br />It&#39;s purely for displaying data, I don&#39;t have write access to the database at all. So for me the #1 priority was to read fast.</p>
<p>It made sense to have the Repository be a singleton since I use a caching layer above it as I wrote about here:<br /><a href="http://www.tigraine.at/2009/05/12/kaerntenat-caching-and-lazy-loading/" rel="nofollow"></a><a href="http://www.tigraine.at/2009/05/12/kaerntenat-ca.." rel="nofollow">http://www.tigraine.at/2009/05/12/kaerntenat-ca..</a>. (yes, just recently, had some NDA issues before).</p>
<p>So anyway there will only be one initialization of the repository since the cache holds only one reference to the repository. </p>
<p>Sorry for the confusion. <br />greetings Daniel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chuck</title>
		<link>http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/comment-page-1/#comment-2501</link>
		<dc:creator>Chuck</dc:creator>
		<pubDate>Sat, 16 May 2009 01:08:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/#comment-2501</guid>
		<description>Daniel,&lt;br&gt;&lt;br&gt;I read your original post for InjectableDataContext, &lt;a href=&quot;http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/&quot; rel=&quot;nofollow&quot;&gt;http://www.tigraine.at/2009/04/10/how-to-make-a...&lt;/a&gt;, and assumed you would&#039;ve implemented you UserRepository differently using Windsor.&lt;br&gt;&lt;br&gt;I don&#039;t follow this logic, &quot;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.&quot;  Why would you want your repositories to be singletons?  DataContext is not designed to be used concurrently by multiple threads.  I would&#039;ve assumed your repository constructor would&#039;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.  &lt;br&gt;&lt;br&gt;#     public UserRepository()  &lt;br&gt;#     {  &lt;br&gt;#         this.context = container.Resolve&lt;DataClassesDataContext&gt;();&lt;br&gt;#     }  &lt;br&gt;&lt;br&gt;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&#039;t have multiple threads attempting to use the same context.&lt;br&gt;&lt;br&gt;If you were using your Repository as a singleton I don&#039;t know how you could possibly get methods like these to work with your context:&lt;br&gt;&lt;br&gt;&lt;br&gt;        //Insert/Delete&lt;br&gt;        public void Add( BlogUser user) {&lt;br&gt;            context.Users.InsertOnSubmit( user);&lt;br&gt;        }&lt;br&gt;&lt;br&gt;        public void Delete( BlogUser user) {&lt;br&gt;            context.Users.DeleteOnSubmit( user);&lt;br&gt;        }&lt;br&gt;&lt;br&gt;        //Persistence&lt;br&gt;        public void Save() &lt;br&gt;        {&lt;br&gt;            context.SubmitChanges();&lt;br&gt;        }</description>
		<content:encoded><![CDATA[<p>Daniel,</p>
<p>I read your original post for InjectableDataContext, <a href="http://www.tigraine.at/2009/04/10/how-to-make-a-linq2sql-datacontext-ioc-friendly/" rel="nofollow"></a><a href="http://www.tigraine.at/2009/04/10/how-to-make-a.." rel="nofollow">http://www.tigraine.at/2009/04/10/how-to-make-a..</a>., and assumed you would&#39;ve implemented you UserRepository differently using Windsor.</p>
<p>I don&#39;t follow this logic, &#8220;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.&#8221;  Why would you want your repositories to be singletons?  DataContext is not designed to be used concurrently by multiple threads.  I would&#39;ve assumed your repository constructor would&#39;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.  </p>
<p>#     public UserRepository()  <br />#     {  <br />#         this.context = container.Resolve&lt;DataClassesDataContext&gt;();<br />#     }  </p>
<p>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&#39;t have multiple threads attempting to use the same context.</p>
<p>If you were using your Repository as a singleton I don&#39;t know how you could possibly get methods like these to work with your context:</p>
<p>        //Insert/Delete<br />        public void Add( BlogUser user) {<br />            context.Users.InsertOnSubmit( user);<br />        }</p>
<p>        public void Delete( BlogUser user) {<br />            context.Users.DeleteOnSubmit( user);<br />        }</p>
<p>        //Persistence<br />        public void Save() <br />        {<br />            context.SubmitChanges();<br />        }</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tani001</title>
		<link>http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/comment-page-1/#comment-2498</link>
		<dc:creator>tani001</dc:creator>
		<pubDate>Mon, 11 May 2009 15:29:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.tigraine.at/2009/04/22/locking-with-linq-to-sqls-deferred-execution-in-an-iqueryablet-szenario/#comment-2498</guid>
		<description>i think you work really hard for this. This are really cool. Thanks for sharing this information.</description>
		<content:encoded><![CDATA[<p>i think you work really hard for this. This are really cool. Thanks for sharing this information.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
