are there pros or contras, keeping a connection to a (sqlite) database ?
news1234 at free.fr
Thu Sep 9 10:41:50 CEST 2010
On 09/09/2010 12:29 AM, CM wrote:
> On Sep 8, 1:09 pm, Stef Mientki <stef.mien... at gmail.com> wrote:
>> I wrap my database in some class, and on creation of the instance, a connection to the database is
>> and will stay connected until the program exists, something like this:
>> self.conn = sqlite3.connect ( self.filename )
>> Now I wonder if there are pros or contras to keep the connection to the database continuously "open" ?
>> Stef Mientki
> I do the same thing--good to hear from John that keeping it open is
> But another question that this provokes, at least for me is: what
> happens when you call .connect() on the same database multiple times
> from within different parts of the same app? Is that bad? And is it
> that there now multiple connections to the database, or one connection
> that has multiple names in different namespaces within the app?
Do you talk about a multithreaded environment?
or only about an environment with logically separate blocks (or with
and multiple objects each keeping their own connection.
As far as I know sqlite can be compiled to be thread safe, but is not
necessarily be default.
No idea about the library used b python.
I personally just started sqlite in one of my apps with multithrading
and in order to be safe I went for the conservative approach
connect, perform transactions, commit and close.
However this is probably overkill and later in time I might also ty to
keep connections open in order to increse performance.
> I'm not even sure what a "connection" really is; I assumed it was
> nothing more than a rule that says to write to the database with the
> file named in the parentheses.
> Further elaboration from the community would be helpful.
More information about the Python-list