osimons wrote:
> On Dec 13, 9:49 pm, Omry Yadan <[email protected]> wrote: > >> I believe I figured it out, and uncovered a serious bug with the pooling >> of SQLite connections. >> >> the problem is that there is NO POOLING for sqlite connections. >> >> from sqlite_backend.py : >> >> class SQLiteConnection(ConnectionWrapper): >> """Connection wrapper for SQLite.""" >> >> __slots__ = ['_active_cursors'] >> poolable = have_pysqlite and os.name == 'nt' and sqlite_version >= 30301 >> >> problem is that my linux is not an 'nt' :), so poolable is false. >> >> this in turn cause return_cnx to not pool the connection when it's returned: >> >> so, effectively - there is currently no connection pooling for sqlite >> for non nt machines. >> >> so, if you put your server under stress, it spawns many many sqlite >> connections, which eventually causes 'database is locked', and >> 'connection timeout' errors. >> >> Omry Yadan wrote: >> >>> Sorry for the late response. >>> a reminder: >>> I am using trac with wsgi, when trac comes under stress my apache server >>> locks up, once it's running out of worker threads. >>> >>> You suggested that the problem may have been solved in later version of >>> sqlite. I am now running with 3.5.9 and upgraded to python 2.5 - >>> but the problem is still there. >>> > > Hi again Omry, > > I've look into this after our IRC session yesterday. I cannot find any > setting or assumption that we can use to determine if a pooling should > be enabled. The sqlite.threadsafety read setting seems to be set to 1 > in source, reagardless of compile settings - I'd like to use it, but > don't trust it feeling it says more about the python side more than > the underlying actual sqlite lib... > > Anyway some more links of interest: > > * http://www.sqlite.org/faq.html#q6 > * http://www.sqlite.org/cvstrac/wiki?p=MultiThreading > * http://trac.edgewall.org/changeset/4493 > * http://trac.edgewall.org/ticket/2196 > * http://oss.itsystementwicklung.de/trac/pysqlite/ticket/187 > * > http://oss.itsystementwicklung.de/trac/pysqlite/changeset/334%3A353e0026f76c/ > > The last changeset seems to indicate improved detection of the > situation in latest pysqlite version(s). > > We need to improve our detection of poolability of pysqlite, but I'm > just not sure what the best approach is. Other devs may be more likely > to decide on the best strategy - I hope :-) > > Hi Simon, You can try the sqlite3_threadsafe call : http://www.sqlite.org/c3ref/threadsafe.html Remy mentioned that it's probably a bug in pysqlite: http://oss.itsystementwicklung.de/trac/pysqlite/ticket/187 Maybe it was resolved since then? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
