Re: [Firebird-net-provider] A thread-safety workarround
On Sat, Apr 17, 2010 at 18:54, Ivan Arabadzhiev
intelru...@unrealsoft.net wrote:
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 :)
It's much harder and expensive to have locks in code then sometime
spin up a new connection.
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com
--
___
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
Mon, 03 May 2010 12:55:16 +0300, Jiri Cincura disk...@cincura.net: On Sat, Apr 17, 2010 at 18:54, Ivan Arabadzhiev intelru...@unrealsoft.net wrote: 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 :) It's much harder and expensive to have locks in code then sometime spin up a new connection. On the client - yes, on the server - not really :). Plus having a single connection suggests it`s all or nothing and you can`t have a single tcp stream broken, while the other one gets lucky and so on. Looking back - it`s a bad habbit of mine, which should not be spread (hope it`s not catchy :D). BTW Could I reroute the .net client to fbclient.dll v 2.5. (calling it embedded on connection) and will it break if I were to use it in multiple threads (or is most of the code native and therefore thread safe) ? -- Sanity is a sin! -- ___ 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 Mon, May 3, 2010 at 12:03, Ivan Arabadzhiev
intelru...@unrealsoft.net wrote:
BTW Could I reroute the .net client to fbclient.dll v 2.5. (calling it
embedded on connection) and will it break if I were to use it in multiple
threads (or is most of the code native and therefore thread safe) ?
I don't think so. There's still lot of code in higher levels and this
could break the managed part of code. Also take into account the cost
of marshaling.
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com
--
___
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
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
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
[Firebird-net-provider] A thread-safety workarround
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. Actually, I am thinking about keeping up with the fb 2.5 client in aspects of thread safety (possibly concurrent transactions support), so I wanted to ask two things : 1 Is someone else working on the issue or is there a point for me to try it (I know it probably won`t be a one-night-job, but if no one else is working on the issue I figure a few weeks will not be a problem) 2 I have no actual experience in team development - what would be the proper way to try to implement that stuff (without getting in the way that is)? -- 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
