the code looks fine. things id make sure of are that youre on 0.3.7
of SA, youre on a very recent version of MySQLDB. also the
"use_threadlocal" is probably not needed on your engine() and its
worth trying without it since its not as widely tested.
also the common complaint with mod_python is that apache threads dont
mix well with Python threads, although the mod_python folks will
specifically note that its the way native extension modules are
implemented that creates problems (such as mysqldb). so id also
ensure youre on the very latest mod_python and also see if people
have had issues with threaded mod_python and mysqldb specifically.
personally, i never use a threaded apache, it gives me the heebie
jeebies. for threading id go with apache mod_proxy talking to a WSGI
server. it might not be a bad test to adapt your applciation to a
WSGI interface and see if you still have the threading issues sans
apache.
On May 31, 2007, at 2:53 PM, Gambit wrote:
>
> Hello list,
>
> I've been having many stability problems with my first SQLAlchemy +
> mod_python application. By now I'm thinking it's all my fault and I'm
> not using these tools the way they are intended to be used. So I would
> like to know how do others organize their code to get something
> that works.
>
> I got the following advice from a previous post by Michael Bayer:
>
>> mappers are intended to be create-once-per-class objects (usually at
>> the module level), whereas sessions are usually instantiated
>> once-per-request, queries once-per-operation
>
> What I do is to create an engine in a separate module that is imported
> at the beginning of my app. This module, which I call dbinit.py,
> resembles this:
>
> db = sa.create_engine('mysql://user:[EMAIL PROTECTED]/mydb',
> use_threadlocal=True, echo_pool=True)
> metadata = sa.BoundMetaData(db)
> users_table = sa.Table('Users', metadata, autoload=True)
>
> class User(object):
> pass
>
> sa.orm.clear_mappers()
> sa.mapper(User, users_table)
>
> That's it. I import it once at the beginning of the app and just
> assume
> SQLALchemy keeps a pool of connections for me and whenever I use
> the db
> variable to create sessions it'll be available and do the right
> thing. I
> don't use any connect/disconnect methods or anything like that. In
> fact
> a typical method in my mod_python site looks just like this:
>
> import logging
> import sqlalchemy as sa
> from dbinit import *
>
> def justatest(req):
> dbsession = sa.create_session(bind_to=db)
> query = dbsession.query(User)
> requested_uid = sanitize(req.form['uid'])
> try:
> user = query.get_by(Uid=requested_uid)
> except sa.exceptions.SQLError, details:
> logging.debug("got this error: %s" % details)
> dbsession.close()
> return "Yet another crash"
> else:
> dbsession.close()
> return show_message(req, "Looks good")
>
> I have many methods that follow that same structure. And the whole
> thing
> works rather well while I'm the only one using it... but in the real
> world I get InterfaceError exceptions all the time, which others in
> this
> list identified as threading issues.
>
> Michael Bayer also added that I should...
>
>> ensure that you arent sharing connections or sessions between
>> concurrently
>> executing threads.
>
> I believe my code above is free from these errors... Right? I leave
> SQLAlchemy the task of handling connections and I create and close
> sessions with each http request.
>
> So that's it. I don't know if my app uses a weird structure that
> brings
> SQLAlchemy to its knees and I should be doing something else. How
> do you
> people organize your code in a simple mod_python + SQLAlchemy
> application? Is my code just plain odd? Any particular hints? Does
> anyone know of a solid open source mod_python + SQLALchemy
> application I
> could use as an example?
>
> Best regards,
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" 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/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
