On 09/09/2010 12:29 AM, CM wrote: > On Sep 8, 1:09 pm, Stef Mientki <stef.mien...@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 -- http://mail.python.org/mailman/listinfo/python-list
