Re: [Firebird-net-provider] A thread-safety workarround
Hi, Haven`t really thought about the ADO .NET specificatian actually (wasntme). The idea of using RWLS instead of Mutex is based on my current coding style, since I was looking mostly at thread-proofing the FbConnection object itself(at lowest possible lvl, and maybe FbTransaction, but nothing more), and I don`t really On Fri, Apr 16, 2010 at 18:18, Ivan Arabadzhiev intelru...@unrealsoft.net wrote: Hi, I`ve asked before (and yes, I remember the provider is not thread safe), but I recently started using the 3.5 framework and was hit by a lightning. Could the FirebirdConnection object get a public ReaderWriterLockSlim member? It would be just about one line of code (definition ...), and would be sort of a workarround for anyone like me, who can wrap connection operations in try/catche/finally blocks. I don't know how the RWLockSlim relates to try/catch/finally. Anyway having any kind of lock of anchor for locking isn't going to do thread safe provider. The FbTransaction, FbCommand etc. have methods operating with database, hence you can easily screw something up if you don't do locking properly. And you can do the locking properly (in fact it's more likely, than relying on part of client) if *you* do yourself. Also take into account, that isn't adhere to ADO.NET design. BTW the RWLockSlim isn't good for this purpose, as in 99,999% cases you need mutual exclusion (aka everybody is writer) because you don't know (and shouldn't know) what's going on in lower layers. Also notice how an application will scale if more threads will be using one connection. It will be very bad. It's a similar story as thread vs. threadpool and the solution is (un)surprisingly similar. On the other hand, you can grab sources and add the member yourself, if you think you need it. -- Sanity is a sin! -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
[Firebird-net-provider] [FB-Tracker] Created: (DNET-311) Connection pool cleanup thread rework as Timer
Connection pool cleanup thread rework as Timer -- Key: DNET-311 URL: http://tracker.firebirdsql.org/browse/DNET-311 Project: .NET Data provider Issue Type: Improvement Components: ADO.NET Provider Affects Versions: 2.5.2 Reporter: Jiri Cincura Assignee: Jiri Cincura Priority: Minor The connection pool cleanup thread is actually sleeping a lot of time and so just wasting system resources. Rework it to Timer to be more efficient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Re: [Firebird-net-provider] A thread-safety workarround
On Sat, Apr 17, 2010 at 14:35, Ivan Arabadzhiev
intelru...@unrealsoft.net wrote:
(and I hate mutexes) :). I guess I`ll get some sort of
If you mean the Mutex class, then this class isn't the best choice in
many scenarios. It's doing too much. But in general I don't believe in
mut-ex at all. It's wasting resources blocking threads (or spinning).
wrapper for the provider to handle threads ... I`m tired of syncing them
'the long way'
I don't know your scenario... Why not to have one object per thread?
Why not to have a worker thread (though creating thread explicitly
hurt performance) doing the database work (which is what the mut-ex
will end up actually doing) - this is inverting the problem.
Maybe you're trying to do something, that's doable better way and
somebody in list already tested the wrong paths, and will answer.
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Re: [Firebird-net-provider] A thread-safety workarround
Well maybe thread-safety is not the exact term to use - what I ment was an object, which will not break if accessed by multiple threads (not actually capable of doing =2 things at once). As for my scenario - it is relatively simple : Most of the time - users do not need the database itself because a background class is doing synchronization between the main database, the local copy and the memory of the workstation. Two times a day, a user makes a report. I have thought about making the report on a second connection, created and used on the GUI thread, but the information depends on the data in RAM/local storage, which may not be saved at the time of generating, which is why I mut-ex things in anyway. Actually I just don`t like the idea of unnesesary connections(I have a thing about wasted resources) so I use just one, doing one thing at a time on different threads(gui or background). I find the idea useful and thought other people might like it :) Thanks anyway, a second opinion usually saves me a few weeks of recode :D Sat, 17 Apr 2010 21:38:07 +0400, Jiri Cincura disk...@cincura.net: On Sat, Apr 17, 2010 at 14:35, Ivan Arabadzhiev intelru...@unrealsoft.net wrote: (and I hate mutexes) :). I guess I`ll get some sort of If you mean the Mutex class, then this class isn't the best choice in many scenarios. It's doing too much. But in general I don't believe in mut-ex at all. It's wasting resources blocking threads (or spinning). wrapper for the provider to handle threads ... I`m tired of syncing them 'the long way' I don't know your scenario... Why not to have one object per thread? Why not to have a worker thread (though creating thread explicitly hurt performance) doing the database work (which is what the mut-ex will end up actually doing) - this is inverting the problem. Maybe you're trying to do something, that's doable better way and somebody in list already tested the wrong paths, and will answer. -- Sanity is a sin! -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
