Hello, Josh. Thanks for the information.
I couldn't find the message "Can't reconnect until invalid transaction is rolled back" in the output you pasted and I think the link to the FAQ refers to another type of issue. According to the traceback, the exception is raised when the user object is loaded. Before that, the plugin would've issued another query to verify the username and password, and it seems like that query did succeed (you can see it by increasing the verbosity of the SQLAlchemy logger). So somehow, the connection is lost between those two queries (while the repoze.who middleware is being executed). I can't see anything on the plugin that would cause that -- in fact, as I mentioned yesterday, this is the first time I hear about this in 2 years. I've been reading about that error on the MySQL documentation and it seems like all the possible causes are external to the application: http://dev.mysql.com/doc/refman/5.0/en/gone-away.html There's some troubleshooting information there. If you can't still find the problem, I'd recommend writing to the SQLAlchemy mailing list with the output of the logger at the INFO level -- You can CC me on that email so that I can keep an eye on it and see if I can help. You can try and tweak the Session if you want; it may or may not help. I don't think handling the exception in repoze.who.plugins.sa is an appropriate solution because we'd silencing a problem that should be fixed. HTH. - Gustavo. On Nov 16, 2:07 am, Josh Kelley <josh...@gmail.com> wrote: > On Nov 15, 4:54 pm, Gustavo Narea <m...@gustavonarea.net> wrote: > > > The only thing I can think of is that the repoze.who middleware was > > added in the wrong order. Please have a look at this > > example:https://bitbucket.org/Gustavo/whatpylonsproject/src/tip/pylonssecured... > > > I don't remember seeing that error before. Can you please paste the > > traceback if the location of the middleware is not the problem? > > Thanks for the reply. > > My middleware.py looks very similar to the one you linked. The middle > is slightly different (I haven't done anything with caching, and I > added ToscaWidgets; neither looks like it should be a problem): > > # Routing/Session/Cache Middleware > app = RoutesMiddleware(app, config['routes.map'], singleton=False) > app = SessionMiddleware(app, config) > > # CUSTOM MIDDLEWARE HERE (filtered by error handling middlewares) > > app = twa.make_middleware(app, { > 'toscawidgets.framework': 'pylons', > 'toscawidgets.framework.default_view': 'mako', > }) > app = add_auth(app) > > if asbool(full_stack): > # Handle Python exceptions > app = ErrorHandler(app, global_conf, > **config['pylons.errorware']) > > My add_auth uses repoze.what.plugins.quickstart.setup_sql_auth, like > the one you linked. (Actually, I think I followed your cookbook > article.) > > I posted the traceback tohttp://pastie.org/1301390. > > After investigating a bit more, here's my understanding of the > problem. Please correct me if I'm wrong: > > As described > athttp://www.sqlalchemy.org/trac/wiki/FAQ#Thetransactionisinactivedueto..., > uses of Session should make sure that they end with a call to > rollback(), close(), or remove(). Pylons does this in its > BaseController, but because repoze.who.plugins.sa is configured as > middleware, it executes outside of BaseController's try/finally block, > so any errors it encounters are never rolled back. > > I can think of three solutions: > > 1) Give repoze.what.quickstart a Session object with autocommit=True, > so that it never has to rollback. I guess this would mean creating > two session objects (one for Pylons with autocommit=False, one for > repoze.who / repoze.what with autocommit=True); are there any caveats > with doing this? > 2) Initialize and close the Session within middleware rather than > within the Pylons app (something > likehttp://pypi.python.org/pypi/SQLAlchemyManager/0.1.0?). > 3) Add try/except blocks to repoze.who.plugins.sa. > > #3 seems like the correct solution, but I'm very new to Pylons, > repoze, SQLAlchemy, and WSGI middleware, so I could easily be > misunderstanding something. > > -- > Josh Kelley -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
