> > After that, it's of no use to keep the database open, so it closes it. > > And sends the results obtained back to the client. > > Wow! This is the first I hear that. Wouldn't that be an expensive > operation? (opening, closing, reopening...)
For an embedded database, such as SQLite, yes it would be an expensive, and unnecessary, operation. The open/use/close method is well suited for a client/server engine, however. Many client/server RDBMS engines, such as MS SQL, and I'm pretty sure Oracle, use so-called "connection pooling", where the connections on the server aren't actually deallocated when the client "closes" them, but are instead maintained in a pool on the server. The next client that opens a connection may get a new one, or it may get a reference to a previously used one. If your application holds a connection open even if it has no further use for it, or won't need it for some extended period of time, then that connection's resources aren't available for some other application, which means the server has to allocate more resources for a new one, using up time and memory on the server. The server side resources for the connection being held open aren't actually being used for anything, so they are wasted. Imagine every application that connects to the server doing that. The theory is that allocating and deallocating the resources used by a connection object on the server are actually more time consuming than simply reinitializing the resources associated with an existing object, so not having to create a new one *every* time a client connects saves time on the server and makes the applications that much scaleable. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
