Use a connection within a using clause.

                                using (FbConnection connection = 
OpenConnection())
                                {
                                        using (FbCommand command = new 
FbCommand(commandName, connection))
                                        {
                                                command.CommandType = 
commandType;
                                                if (internalParameters != null)
                                                {
                                                        
command.Parameters.AddRange(internalParameters);
                                                }
                                                
                                                return 
command.ExecuteNonQuery();
                                        }
                                }

This forces the connection to be disposed when finished.
If you are using pooling then the connection will either be returned
to the pool or disposed properly.
You should also use an IDataReader in a using clause.

On Sat, Mar 20, 2010 at 12:15 AM, Jiri Cincura <[email protected]> wrote:
> On Fri, Mar 19, 2010 at 21:39, Bruce Tiffany <[email protected]> wrote:
>> Yes, we can simulate it consistently by using multithreading to simulate 
>> simultaneous users in a web environment.  It bombs every time.
>
> Are you using one connection on more threads (simultaneously)?
>
>> The deal was we were having lingering connections.  Even if you 
>> disconnected, the system maintained a sort of "open connection" in the pool 
>> which could be reused for the next connection request, thus saving a small 
>> amount of overhead.  It was suggested that we "clear all pools" when 
>> disconnecting.
>
> It depends. If you know you're not going to do work with database,
> then clearing pool doesn't hurt.
>
>> The trouble we eventually ran into was that when we cleared all pools, 
>> anyone else who was connected would lose his connection.  Not nice.  In 
>> order to reproduce this in testing, I had to spawn off a bunch of threads to 
>> connect, do some work and disconnect, each thread clearing all pools.  If I 
>> just tested with one connection, I never could get an error, for obvious 
>> reasons.  Well, it didn't take long at all to run into chaos.  The first guy 
>> out would clear the pool(s), and then everybody else blew up.
>
> Can you provide a test case? And put it into tracker.
>
>> Apparently the connections of different simultaneous users using a web app 
>> is quite similar to multithreading.
>
> Kind of. But the pooling is thread safe, only the connection etc. itself 
> isn't.
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>



-- 
Gareth

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Reply via email to