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
On Sat, Apr 17, 2010 at 14:35, Ivan Arabadzhiev
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 blocki
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
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 no
Really, really sorry about the previous post but I guess I hit some sort
of "quick send" button on the Opera :(
To say it shorter - you are probably right, but I still believe in
thread-safety (and I hate mutexes) :). I guess I`ll get some sort of
wrapper for the provider to handle threads .
On Fri, Apr 16, 2010 at 18:18, Ivan Arabadzhiev
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? I
