8

I'm using SQLAlchemy with Flask as shown here: http://flask.pocoo.org/docs/patterns/sqlalchemy/

I have a Selenium test suite that first runs with Firefox and then with Chrome.

Before the start of tests on each browsers, tables in the test database (PostgreSQL) are dropped and created.

It runs perfectly for the first browsers, but for the second browser the SQL create / drop attempt just freezes and no errors are shown.

I believe this is because of open SQLAlchemy sessions, is that correct?

Sri
  • 5,805
  • 10
  • 50
  • 68

2 Answers2

3

I believe this is because of open SQLAlchemy sessions, is that correct?

That's most likely the case. To confirm it, connect to the postgres database and run SELECT * FROM pg_stat_activity;

I'm not sure how you handle the DB creation/dropping but you may want to call dispose() and possibly recreate() on the SQLAlchemy connection pool, after making sure that any checked out connection has been returned (for example, with session.close()).

jd.
  • 10,678
  • 3
  • 46
  • 55
  • A temporary solution for me was to disable transactions i.e. `autocommit=True` as an `engine` parameter. – Sri Dec 21 '12 at 10:40
  • Interesting. I think with autocommit the session returns the connection immediately to the pool. I suppose between the two consecutive tests, your engine and pool are garbage collected, right? Then that would mean you have one or more open transactions at the time your engine is destroyed, each of which keep a connection open to the PG server. – jd. Dec 21 '12 at 10:47
0

This is something that happens to me too on running Flask unittest with SQLAlchemy and Postgres. Many a times, the culprit is an exception, which did not propagate upwards and got stuck. This exception also stops the test from cleaning up properly and hence the freeze.

If you are creating a test suite then call debug method on the suit and it will show the exception. Linked the docs of this method here.

Your observation of an open Sqlalchemy session can also be a reason. I will test a theory of mine based on this observation tomorrow. If it clears some doubts then I will post here.

Look at this answer that shows how you can trigger debugger on exception. Maybe it can help pinpoint problem.

Community
  • 1
  • 1
codecool
  • 5,886
  • 4
  • 29
  • 40
  • For me it was an unclosed transaction. Using `autocommit=True` on my `engine` fixed the problem by basically not working through transactions on postgres. Not sure if this is a long term solution. – Sri Dec 21 '12 at 10:39
  • `autocommit=True` can compromise the consistency of your data, depending on your application. – jd. Dec 21 '12 at 10:49