![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Hi all I'm developing a software written in c# (.NET 2.0) with a SQL server 2005 database. I have 3 modules that need to access database: - a simple ASP.NET website receiving event from remote devices via https calls - a windows service running 24/7 that act as a server - a winform application running as a client with user interface, launched by the user 3 modules use .NET remoting to communicate. In order to query DB actually I'm using a single connection for each module, always opened (for the ASP.NET site I use a static instance of my "dbManager" class)... when I neeed to query the database I use the already opened connection and leave it opened for further operation. Is this acceptable? what kind of problems can cause? Should I use another approach (open and close connection for every operation)? Thanks in advance |
#3
| |||
| |||
|
|
No, this is not a good practice. Instead, create a new connection instance and open it right before you need it. After the operation dispose it. Connection pooling will cache physicall connections for you (given the connecting string is the same). This is the optimal usage. |
|
In your case, you have a serious problem - you use a single connection instance (not thread safe) in a multithreaded app (which asp.net is). |
#4
| |||
| |||
|
|
Hi Miha thanks for your reply ;-) Miha Markic ha scritto: No, this is not a good practice. Instead, create a new connection instance and open it right before you need it. After the operation dispose it. Connection pooling will cache physicall connections for you (given the connecting string is the same). This is the optimal usage. so the best solution is always open and close connection for every operation on database? I know that open connection is an expensive operation, so If I need to open and close for every query I have to do can I produce a performance problem? |
|
In your case, you have a serious problem - you use a single connection instance (not thread safe) in a multithreaded app (which asp.net is). I use lock statements to avoid this problem.... Am I wrong? |
#5
| |||
| |||
|
|
so the best solution is always open and close connection for every operation on database? I know that open connection is an expensive operation, so If I need to open and close for every query I have to do can I produce a performance problem? Not at all. (physicall) connection pooling is working behind the scenes. Performance hit is neglible. In your case, you have a serious problem - you use a single connection instance (not thread safe) in a multithreaded app (which asp.net is). I use lock statements to avoid this problem.... Am I wrong? Yes, you are killing performances. Otherwise not. |
#6
| |||
| |||
|
|
Miha Markic ha scritto: so the best solution is always open and close connection for every operation on database? I know that open connection is an expensive operation, so If I need to open and close for every query I have to do can I produce a performance problem? Not at all. (physicall) connection pooling is working behind the scenes. Performance hit is neglible. In your case, you have a serious problem - you use a single connection instance (not thread safe) in a multithreaded app (which asp.net is). I use lock statements to avoid this problem.... Am I wrong? Yes, you are killing performances. Otherwise not. All my 3 modules works in a multithread environment so.... if I have in my "dbManager" class a single SqlConnection instance to open and close for every operation could be a good solution? or I need to use a new instance in every "dbManager" method? Thanks |
#7
| |||
| |||
|
|
Open connections as you need them and close them immediately. Connection pooling holds onto the physical connection even after you've closed it. From your comments, I "believe" you think each time you open and close a connection, you are going through the expensive connect process. You aren't. As an example. Let's say you needed to walk across the room and pick up a piece of paper. If you had to do this ten times, you'd get tired. Think of connection pooling as someone who will stand beside you and will hold the pieces of paper while you are busy. Then, when you need a piece of paper, it quickly hands it to you and takes it back when you are done. When it thinks you no longer need the piece of paper, it will walk across the room and put the paper back. Kind of a cheesy example but you get the idea... -- Robbe Morris [Microsoft MVP - Visual C#] .NET PropertyGrid Control - ListBox, ComboBox, and Custom Classes http://www.eggheadcafe.com/tutorials...d-control.aspx "Hornet77" <neuro (AT) mancer (DOT) com> wrote in message news:utvkMBV8HHA.980 (AT) TK2MSFTNGP06 (DOT) phx.gbl... Miha Markic ha scritto: so the best solution is always open and close connection for every operation on database? I know that open connection is an expensive operation, so If I need to open and close for every query I have to do can I produce a performance problem? Not at all. (physicall) connection pooling is working behind the scenes. Performance hit is neglible. In your case, you have a serious problem - you use a single connection instance (not thread safe) in a multithreaded app (which asp.net is). I use lock statements to avoid this problem.... Am I wrong? Yes, you are killing performances. Otherwise not. All my 3 modules works in a multithread environment so.... if I have in my "dbManager" class a single SqlConnection instance to open and close for every operation could be a good solution? or I need to use a new instance in every "dbManager" method? Thanks |
#8
| |||
| |||
|
#9
| |||
| |||
|
|
As I have said many times before, this JIT connection strategy is a "best practice" for ASP architectures. It is not always (or even usually) the best choice for "connected" Windows Forms architectures. JIT precludes use of server-side state management which can dramatically improve query performance. Consider that each trip to the ConnectionPool requires the interface to reauthenticate your credentials and reset the connection--these operations are not free and totally unneeded with client/server architectures. |
#10
| |||
| |||
|
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
| |