mod_wsgi + database transaction problems.

[vandevel]

I am wondering if anyone has experienced database transaction problems
using mod_wsgi 1.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 behind mod_wsgi, however it is
not a problem when running the app straight from cherrypy. Clearly,
mod_wsgi is doing something which causes the app to behave in this
manner.

Any insight would be appreciated. Thanks!

[vandevel]

Further to this, SQLObject is using the psycopg2 library.

[Graham Dumpleton]

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.

Graham

[vandevel]

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:

> Grahamth

[GSP]

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!

[Graham Dumpleton]

As you seemed to have a think, didn't really look any further. Plus, I
haven't ever used SQLObject so it is hard for me to say anyway.

All I could suggest is for your to come up with a working example of
the problem using SQLObject directly from a simple WSGI hello world
program and independent of TurboGears. That would make it easier to
debug. It is possible that such a hello world type test program may
work as it may be related somehow to TG or CherryPy internals.

Graham

[Mark Ramm]

I think there's a general way to clear out the SQLObject cache better
than has been done in TG. I think it was added to a more recent
version of SO, and I must admit to not being a regular SO user in the
last year or so.

If somebody using SO could take a look at this ticket, I think it
might have suggestions that lead to a resolution of this issue.

http://trac.turbogears.org/ticket/85

Of course, I use SA and it's been resolved there... But if there's a
good SO solution, we should try to get that figured out.

--Mark Ramm

--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog