Database connection
-
i'm wondoring which is better !! 1.openning the connection to the database and leaving it opened untill the application is closed. 2.closing that connection and openning it again when i a need to connect ,which means i will open and close the connection many times while the application is running !! thanks in advance :)
-
i'm wondoring which is better !! 1.openning the connection to the database and leaving it opened untill the application is closed. 2.closing that connection and openning it again when i a need to connect ,which means i will open and close the connection many times while the application is running !! thanks in advance :)
Just a technical point: assuming that the connection is by the same program to the same file, the connection doesn't get closed and opened lots of times. Most database drivers use connection pooling, which caches the database connection. This increases the speed considerably Personally, I would go with the second option. I don't write database programs often, but with the advent of connection pooling, the speed reduction is virtually eliminated. On the other hand, a program may terminate abnormally; an example of this would be the 'End Process' button in Task Manager. If that happens, I don't know if the connection would get terminated This choice is just my opinion really. It may not be right, but it goes with my general method of retrieving data: get in, read it as quickly and efficiently as possible, get out, deal with the extracted data
-
Just a technical point: assuming that the connection is by the same program to the same file, the connection doesn't get closed and opened lots of times. Most database drivers use connection pooling, which caches the database connection. This increases the speed considerably Personally, I would go with the second option. I don't write database programs often, but with the advent of connection pooling, the speed reduction is virtually eliminated. On the other hand, a program may terminate abnormally; an example of this would be the 'End Process' button in Task Manager. If that happens, I don't know if the connection would get terminated This choice is just my opinion really. It may not be right, but it goes with my general method of retrieving data: get in, read it as quickly and efficiently as possible, get out, deal with the extracted data
thanks for ur reply , but i didn't get the meaning of connection pooling ! and what is the advantage? i thought about it , i think if the program depends on a database which is on pc other than the application pc , it may be better if i use option 2 because of network traffic and security issues beside if the database is on the application pc itself i would use option 1 that is my opinion and am not sure if it is better
-
thanks for ur reply , but i didn't get the meaning of connection pooling ! and what is the advantage? i thought about it , i think if the program depends on a database which is on pc other than the application pc , it may be better if i use option 2 because of network traffic and security issues beside if the database is on the application pc itself i would use option 1 that is my opinion and am not sure if it is better
Connection pooling basically caches the connection. It removes most of the overhead from creating a connection. Most of the database drivers use it. The main advantage of this is speed; there's no need to create a connection and read the data when the database driver's got some of the data already cached
-
Connection pooling basically caches the connection. It removes most of the overhead from creating a connection. Most of the database drivers use it. The main advantage of this is speed; there's no need to create a connection and read the data when the database driver's got some of the data already cached
-
i'm wondoring which is better !! 1.openning the connection to the database and leaving it opened untill the application is closed. 2.closing that connection and openning it again when i a need to connect ,which means i will open and close the connection many times while the application is running !! thanks in advance :)
Option 2 always. I can't think of a good enough reason for option 1.
*Developer Day Scotland - Free community conference Delegate Registration Open
-
oh yee i got it it remembers me deferred execution Linq in .net3.5 deferred execution doesn't have connection pooling :) thanks a lot
Member 4697348 wrote:
it [connection pooling] remembers me deferred execution Linq in .net3.5
What has deferred execution got to do with connection pooling?
*Developer Day Scotland - Free community conference Delegate Registration Open
-
i'm wondoring which is better !! 1.openning the connection to the database and leaving it opened untill the application is closed. 2.closing that connection and openning it again when i a need to connect ,which means i will open and close the connection many times while the application is running !! thanks in advance :)
Option 2 is the way to go. No need to tie up system resources when it is not being used.
-
Member 4697348 wrote:
it [connection pooling] remembers me deferred execution Linq in .net3.5
What has deferred execution got to do with connection pooling?
*Developer Day Scotland - Free community conference Delegate Registration Open
-
deferred execution doesn't keep data retrieved from database at RAM so at every time you need somthing u will get the database data not the memory data that is good when ur database is being updated a lot which is an advantage of linq
That was not my question. My question was "What has deferred execution got to do with connection pooling?" While deferred execution has the effect you describe for LINQ to SQL, deferred execution is not about keeping whether the data is in RAM or not. Deferred execution is about running the LINQ query at the point you want the data from it, not at the point you define the query. If you run your LINQ query on objects that exist only in RAM then it will filter based on the most recent state of the objects rather than the state they were in when you defined the query.
*Developer Day Scotland - Free community conference Delegate Registration Open
-
That was not my question. My question was "What has deferred execution got to do with connection pooling?" While deferred execution has the effect you describe for LINQ to SQL, deferred execution is not about keeping whether the data is in RAM or not. Deferred execution is about running the LINQ query at the point you want the data from it, not at the point you define the query. If you run your LINQ query on objects that exist only in RAM then it will filter based on the most recent state of the objects rather than the state they were in when you defined the query.
*Developer Day Scotland - Free community conference Delegate Registration Open
-
yes , but that is for link to objects but in link to sql the linq queries deals directly with database with no lookong for data at RAm at first. am i right??
EmZan wrote:
but that is for link to objects
It is for all types of LINQ. I used LINQ to Objects as an example of how it works when all the data is in RAM. The principle is the same regardless of where the data is. That was my point. I was expanding your definition as it was too narrow and dealt only with LINQ to SQL when your previous post simply mentions LINQ (without detailing what it was LINQing to). You have still avoided my question on connection pooling. What does deferred execution in LINQ have to do with connection pooling?
*Developer Day Scotland - Free community conference Delegate Registration Open
-
EmZan wrote:
but that is for link to objects
It is for all types of LINQ. I used LINQ to Objects as an example of how it works when all the data is in RAM. The principle is the same regardless of where the data is. That was my point. I was expanding your definition as it was too narrow and dealt only with LINQ to SQL when your previous post simply mentions LINQ (without detailing what it was LINQing to). You have still avoided my question on connection pooling. What does deferred execution in LINQ have to do with connection pooling?
*Developer Day Scotland - Free community conference Delegate Registration Open
as i understand from the obove discussion connection pooling : to keep track of last queried data cashed so that i will no use the database engine to execute a prev. executed query. and that is done using the DataAdapter Object(which fills the DataSet Object) and that what i got from ur prev reply btw DataAdapter is automatically closes the connection after execution(reading or writing) Deffered Execution : as linq queries the data and stores it using a varible , then ther is no need for DataAdapter(the pooling hand). and i'm sure that that variable will be removed after reaing the data ,and the connection is closed. so there is no relation between conn-pooling and deff. exec. as i understand
-
as i understand from the obove discussion connection pooling : to keep track of last queried data cashed so that i will no use the database engine to execute a prev. executed query. and that is done using the DataAdapter Object(which fills the DataSet Object) and that what i got from ur prev reply btw DataAdapter is automatically closes the connection after execution(reading or writing) Deffered Execution : as linq queries the data and stores it using a varible , then ther is no need for DataAdapter(the pooling hand). and i'm sure that that variable will be removed after reaing the data ,and the connection is closed. so there is no relation between conn-pooling and deff. exec. as i understand
EmZan wrote:
connection pooling : to keep track of last queried data cashed so that i will no use the database engine to execute a prev. executed query.
Nope. It keeps track of the previously query CONNECTION only so it doesn't have to reestablish a connection to the database. This makes it faster to establish a new connection. Any queries are done against the database, even if it is the same query as the previous time.
EmZan wrote:
and that is done using the DataAdapter Object(which fills the DataSet Object) and that what i got from ur prev reply
I've never mentioned the DataAdapter. It is an evil thing.
EmZan wrote:
DataAdapter is automatically closes the connection after execution(reading or writing)
Well, it says it closes the connection, but just like everything else it simply returns it too the pool. Connection Pooling happens on the SqlConnection object which everything that connects to a database must use. LINQ or not.
*Developer Day Scotland - Free community conference Delegate Registration Open
-
EmZan wrote:
connection pooling : to keep track of last queried data cashed so that i will no use the database engine to execute a prev. executed query.
Nope. It keeps track of the previously query CONNECTION only so it doesn't have to reestablish a connection to the database. This makes it faster to establish a new connection. Any queries are done against the database, even if it is the same query as the previous time.
EmZan wrote:
and that is done using the DataAdapter Object(which fills the DataSet Object) and that what i got from ur prev reply
I've never mentioned the DataAdapter. It is an evil thing.
EmZan wrote:
DataAdapter is automatically closes the connection after execution(reading or writing)
Well, it says it closes the connection, but just like everything else it simply returns it too the pool. Connection Pooling happens on the SqlConnection object which everything that connects to a database must use. LINQ or not.
*Developer Day Scotland - Free community conference Delegate Registration Open
thanks for clarification ,it's realy a good info but i have many questions plz 1.why did u call the data adapter an evil :confused: i'm always using it in my application(actually my 4 applications)i'm a junior btw 2.u said that any query is done against the database! what i know is that dataAdapters keeps queried data and i use it many times without going to the database again and again for the same query and if it's wrong , i'd say that i read before at a limq tutorial that reading the most recent data is an advantage that it means that there is a technology that reads old data many times without going to the database , as i mentioned :sigh:
-
thanks for clarification ,it's realy a good info but i have many questions plz 1.why did u call the data adapter an evil :confused: i'm always using it in my application(actually my 4 applications)i'm a junior btw 2.u said that any query is done against the database! what i know is that dataAdapters keeps queried data and i use it many times without going to the database again and again for the same query and if it's wrong , i'd say that i read before at a limq tutorial that reading the most recent data is an advantage that it means that there is a technology that reads old data many times without going to the database , as i mentioned :sigh:
EmZan wrote:
1.why did u call the data adapter an evil i'm always using it in my application(actually my 4 applications)i'm a junior btw
Data Adapters are used to copy data into a DataSet or DataTable. These are large clunky constructs that almost always are under-utilised. So they end up taking more memory than they actually need for the job you use them for. The prefered solution is to take the data and put it in a domain model without the use of DataAdapters. LINQ to SQL goes some way to help achieve that easily. Previously you needed to use a DataReader (which a Data Adapters uses internally anyway) to get the data out and into your model.
EmZan wrote:
2.u said that any query is done against the database! what i know is that dataAdapters keeps queried data and i use it many times without going to the database again and again for the same query
The Data Adapter dumps a disconnected copy of the data into a DataSet or DataTable. You are querying against that disconnected data. You never go back to the DataAdapter, you go back to the DataSet or DataTable. A DataAdapter's roll is to suck the data out of the database and make a copy of it. If it was a proper caching mechanism it would be relatively seamless. In otherwords you wouldn't know if it were cached or not.
*Developer Day Scotland - Free community conference Delegate Registration Open
-
EmZan wrote:
1.why did u call the data adapter an evil i'm always using it in my application(actually my 4 applications)i'm a junior btw
Data Adapters are used to copy data into a DataSet or DataTable. These are large clunky constructs that almost always are under-utilised. So they end up taking more memory than they actually need for the job you use them for. The prefered solution is to take the data and put it in a domain model without the use of DataAdapters. LINQ to SQL goes some way to help achieve that easily. Previously you needed to use a DataReader (which a Data Adapters uses internally anyway) to get the data out and into your model.
EmZan wrote:
2.u said that any query is done against the database! what i know is that dataAdapters keeps queried data and i use it many times without going to the database again and again for the same query
The Data Adapter dumps a disconnected copy of the data into a DataSet or DataTable. You are querying against that disconnected data. You never go back to the DataAdapter, you go back to the DataSet or DataTable. A DataAdapter's roll is to suck the data out of the database and make a copy of it. If it was a proper caching mechanism it would be relatively seamless. In otherwords you wouldn't know if it were cached or not.
*Developer Day Scotland - Free community conference Delegate Registration Open
-
i'm wondoring which is better !! 1.openning the connection to the database and leaving it opened untill the application is closed. 2.closing that connection and openning it again when i a need to connect ,which means i will open and close the connection many times while the application is running !! thanks in advance :)
Yep, number two. But what that means depends on what the application does.
-
i'm wondoring which is better !! 1.openning the connection to the database and leaving it opened untill the application is closed. 2.closing that connection and openning it again when i a need to connect ,which means i will open and close the connection many times while the application is running !! thanks in advance :)
Hi, the answer is that in ADO.NET you should always close the connection when it isn't in use. The connection classes manage the underlying TCP connection for you, so although you are "logically" closing the connection you are not in fact incurring the cost of tearing down and reestablishing the database connection each time. In practice this makes the most difference in server apps where connection pooling is of great use. Whenever your code closes a connection it in fact simply releases that connection to the pool, and the next time an instance of a connection is constructed that uses the exact same connection string the pre-existing connection is returned. (There is something involved to make the connection state as if it was a freshly established one - see 'sp_reset' in SQL Server, not sure exactly how this is implemented with the other providers.) But even in a desktop app where each client has a dedicated connection to the database and no pooling takes place it's considered good practice to open and close the connection. I think it is; it makes error handling a little easier. You still have to catch exceptions and perhaps log and present errors, but if the user wishes to retry an operation there's no additional logic to check the state of the connection or find out if it's necessary to open it first, because you simply *always* open it where you need it and close it when you're done with it. I personally use a simple connection wrapper class to centralize the code implementing the patterns I wish to use. You may not bother doing this if you use code generation for most of your data access code, but if you hand-code this stuff it makes a huge difference - much less code, far fewer errors, and much easier debugging. And if you just put this class in a separate library and never put anything app-specific in it you'll start building reusable code that has applications everywhere. For example, with my Connection class you can do very common tasks like these very easily:
// Get a connection from configuration. Why rewrite the same code all over the place?
Connection c = Connection.FromConfig("mainDB");// Similar with the open-and-close logic. Why not centralize it so it's transparent?
int count = c.ExecuteScalar("select count(*) from [table] where [col] < @p0", value);// SqlTransaction is a mess; it doesn't support nesting, and you must write code to associate each
// SqlCommand with the transaction object before executing it. Why not automate this ted -
EmZan wrote:
1.why did u call the data adapter an evil i'm always using it in my application(actually my 4 applications)i'm a junior btw
Data Adapters are used to copy data into a DataSet or DataTable. These are large clunky constructs that almost always are under-utilised. So they end up taking more memory than they actually need for the job you use them for. The prefered solution is to take the data and put it in a domain model without the use of DataAdapters. LINQ to SQL goes some way to help achieve that easily. Previously you needed to use a DataReader (which a Data Adapters uses internally anyway) to get the data out and into your model.
EmZan wrote:
2.u said that any query is done against the database! what i know is that dataAdapters keeps queried data and i use it many times without going to the database again and again for the same query
The Data Adapter dumps a disconnected copy of the data into a DataSet or DataTable. You are querying against that disconnected data. You never go back to the DataAdapter, you go back to the DataSet or DataTable. A DataAdapter's roll is to suck the data out of the database and make a copy of it. If it was a proper caching mechanism it would be relatively seamless. In otherwords you wouldn't know if it were cached or not.
*Developer Day Scotland - Free community conference Delegate Registration Open
This advice leaves me feeling rather ambivalent. On the one hand Colin appears to know what he's talking about, on the other he appears to be one of those dogmatic people who think that there is one way that is "the best" regardless of circumstances. I must emphasize that this is merely my impression, how I think the posts read, not a claim that Colin IS such a dogmatic person. (Perhaps he will reply and we will find out.) Personally I think data adapters are useful and the disconnected data model can be enough for many things. Sure, if you have a fancy entity layer it would be ideal if the data can be persisted and reloaded as efficiently as possible, without any dataset intermediaries, but in many applications the truth is whether or not such an intermediary exists makes absolutely no difference to the value or usefulness of your application. In my view, very few dogmas are of any use in programming. Sure, you should use StringBuilder and not string if manipulating string data, but even this makes little difference if the strings are small and modifications few. :)