are there pros or contras, keeping a connection to a (sqlite) database ?

[News123]

On 09/09/2010 12:29 AM, CM wrote:
> On Sep 8, 1:09 pm, Stef Mientki <stef.mien... at gmail.com> wrote:
>>  hello,
>>
>> I wrap my database in some class, and on creation of the instance, a connection to the database is
>> created,
>> 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" ?
>>
>> thanks,
>> Stef Mientki
> 
> I do the same thing--good to hear from John that keeping it open is
> OK.
> 
> 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?
CM,

Do you talk about a multithreaded environment?
or only about an environment with logically separate blocks (or with
generators),
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.
> 
> Thanks,
> Che