tag:blogger.com,1999:blog-5604446423470865692.post1541722314720121123..comments2023-10-30T23:41:00.486+11:00Comments on Ehsan's Software Development Brain Dump: SingletonEhsanhttp://www.blogger.com/profile/16242681690414857239noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5604446423470865692.post-79719284642820323332008-05-01T02:20:00.000+10:002008-05-01T02:20:00.000+10:00G'day dearest Farzad and Ehsan,Dear Ehsan! I'd hav...G'day dearest <B>Farzad</B> and <B>Ehsan</B>,<BR/><BR/>Dear <B>Ehsan</B>! I'd have submitted this comment much sooner should I had read this post at its very beginning; my apologies as I had no idea you've got such a wonderful blog.<BR/><BR/>Well, to be perfectly superhonest, multi-threaded usage of live connection is provider-specific. Microsoft's famous provider for <B>Microsoft SQL Server</B>, <B>SqlClient</B>, does support asynchronous command execution - not to be confused with ADO.NET 2's async command execution. So that an open <B>SqlConnection</B> instance could be shared between two threads without any guards, and then each thread could execute its own <B>SqlCommand</B> instances. <B>ADO.NET</B> takes care of the rest so that the command execution might be blocked till the other thread's command get completed, and data fetched if any. The surprising part, it's not a widely known feature; funny huh?! :)<BR/><BR/>By the way, as an architect I've never recommended my clients going for it because there are some architectural, implementation, and deployment considerations/restrictions which I'm not gonna put here. As an example only, most of the time, it does worth paying the 35+ KB memory consumption per sql-connection, instead of getting stuck down with those implementation difficulties. The traditional and easy-to-learn connection pool wins in most cases.<BR/><BR/>Dear <B>Farzad</B>?! Emmm!!! I basically do not recommend using Thread Local Storage (TLS) the way you mentioned, because the solution has great negative impact on the resource management as thread's local references donot support disposable objects; whilst connections are among most expensive resources! Therefore, you must manage such resources manually. By the way, as our dearest <B>Ehsan</B> mentioned, it'd give you a replacement option for the dictionary; there are few pros and cons applicable to both options, you know!<BR/><BR/>Cheers,<BR/>Jamal MavadatJamal Mavadathttps://www.blogger.com/profile/16234548896627503751noreply@blogger.comtag:blogger.com,1999:blog-5604446423470865692.post-1127132050659590422007-05-17T02:37:00.000+10:002007-05-17T02:37:00.000+10:00First visit, best wishesFirst visit, best wishesKambiz G. Rajaiehttps://www.blogger.com/profile/06237922470590019330noreply@blogger.comtag:blogger.com,1999:blog-5604446423470865692.post-49600333263228167252007-05-09T18:23:00.000+10:002007-05-09T18:23:00.000+10:00Farzad,I don't think you're even allowed to share ...Farzad,<BR/>I don't think you're even allowed to share a connection between two different threads. If you try to access a connection object through different threads you will most likely get an exception. Anyhow as you can see in my post in the "Multi-Instanced-Singleton" section I've given an example of a ConnectionManager that will maintain a different instance of itself based on what thread is calling it. <BR/>You can extend that example so instead of storing the ConnectionManager instances in the dictionary, they would be stored in the Thread using GetData and SetData, which for the given example is excellent (since all will be cleaned up when the thread dies) but in general might not work (consider the MDI word processor example).Ehsanhttps://www.blogger.com/profile/16242681690414857239noreply@blogger.comtag:blogger.com,1999:blog-5604446423470865692.post-39207598456320695302007-05-08T19:21:00.000+10:002007-05-08T19:21:00.000+10:00As you mentioned before, it is not possible to exe...As you mentioned before, it is not possible to execute a SQL command from one thread when another thread is inside a transaction in the same connection. <BR/>In this situation we have to open a new DB connection for each thread.<BR/><BR/>I guess using Thread.SetData() and Thread.GetData() will help.<BR/>I can open a new connection for each thread and store the reference in the thread by using Thread.SetData() and I can retrieve the connection by using Thread.GetData().<BR/><BR/>Thread.SetData() and Thread.GetData() are inside the <BR/>public static DBConnectionManager Instance() property.<BR/><BR/>What is your idea for this problem?Unknownhttps://www.blogger.com/profile/11971044372112331803noreply@blogger.comtag:blogger.com,1999:blog-5604446423470865692.post-28156079323549316022007-05-08T19:03:00.000+10:002007-05-08T19:03:00.000+10:00Hi :)Thanks for your detailed explanation.Hi :)<BR/>Thanks for your detailed explanation.Unknownhttps://www.blogger.com/profile/11971044372112331803noreply@blogger.com