> Based on the provided info and configuration, were you able to
> identify a potential cause of the database transaction issues that I
> observed.?
> My work around was admittedly less than ideal and I am still curious
> to know why the problem only occurs when using mod_wsgi.

> Thanks!

> On Mar 29, 1:18 am, vandevel <vande...@gmail.com> wrote:

> > Thanks for the prompt response. I am aware of the problems with using
> > SQLObject in a multi-process environment
> > so mod_wsgi was configured to run in daemon mode. I'm not entirely
> > familiar with apache configuration so I am guessing the daemon
> > process is running as Apache user since I did not explicitly set that
> > configuration option.

> > I did discover an issue in the my code which lead to the error when
> > mod_wsgi is enabled. I loaded a dictionary of SQLObject instances at
> > module scope in a controller module in order to avoid hitting the
> > database with each request.  This dictionary of course persists across
> > transactions so perhaps that indicates something. To resolve the
> > issue, I simply copied the data into
> > wrapper objects in order to disconnect the data from the SQLObject
> > machinery. That did the trick, however, I am a curious to know if
> > there is a more intelligent solution. It is worth pointing out that I
> > did set cacheValues=False in the SQLObject class definition and that
> > did not solve the problem.

> > The apache configuration is as follows(purged of sensitive details of
> > course):

> > WSGIDaemonProcess site-1 threads=25
> > WSGIProcessGroup site-1

> > Alias /static /project_dir/static

> > WSGIScriptAlias / /project_dir/project.wsgi

> > NameVirtualHost *:80
> > <VirtualHost *:80>
> >         ServerAdmin webmaster@localhost

> >         DocumentRoot /project_dir

> >         # Possible values include: debug, info, notice, warn, error,
> > crit,
> >         # alert, emerg.
> >         LogLevel warn

> >         CustomLog /var/log/apache2/access.log combined
> >         ServerSignature On

> >         <Directory /project_dir>
> >            Order deny,allow
> >            Allow from all
> >         </Directory>
> > </VirtualHost>

> > Thanks for your help!

> > On Mar 28, 10:48 pm, Graham Dumpleton <Graham.Dumple...@gmail.com>
> > wrote:

> > > On Mar 29, 10:17 am, vandevel <vande...@gmail.com> wrote:

> > > > I am wondering if anyone has experienced database transaction problems
> > > > usingmod_wsgi1.3.
> > > > My turbogears project is based on TG 1.0.4.4 using SQLObject and I am
> > > > observing this error when executing some controller methods:

> > > > AssertionError: This transaction has already gone through ROLLBACK;
> > > > begin another transaction.

> > > > This only occurs when running the app behindmod_wsgi, however it is
> > > > not a problem when running the app straight from cherrypy. Clearly,mod_wsgiis doing something which causes the app to behave in this
> > > > manner.

> > > More information required.

> > > Are you running your application in embedded mode of mod_wsgi or in
> > > daemon mode? If in embedded mode, you did read about the problems with
> > > SQLObject and multiprocess web servers in:

> > >  http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears

> > > If running in daemon mode, are you running it as Apache user, or did
> > > you configure daemon process to run as you? Also, if in daemon mode,
> > > how many processes did you set for the daemon process group. Like
> > > above, if more than one and using multiprocess server, there can be
> > > issues, although it shouldn't be what you are seeing.

> > > Anyway, post what the mod_wsgi configuration you are using is from
> > > your Apache configuration.

> > > Grahamth