Hello Graham, 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> > wrote: > > > On Mar 29, 10:17 am, vandevel <[EMAIL PROTECTED]> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
