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.
> 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.
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:
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.
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):
> 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:
> 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.
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):
> 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:
> > 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.
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
On Apr 1, 11:02 am, GSP <baycity...@gmail.com> wrote:
> 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):
> > 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:
> > > 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.
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.
On Mon, Mar 31, 2008 at 9:02 PM, GSP <baycity...@gmail.com> wrote:
> 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 <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):
> > 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:
> > > 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.
