views:

404

answers:

1

Is there any way to share same transaction between two threads in a django-based code?

The problem is that I have 1.1's TestCase (those that wrap individual tests into transactions) that are intended to test code that is running in a different thread [a sort of asynchronous testing]. So these test create some data that is intended to be used by this second thread. Obviously, since this data is created within a transaction scope, it is not visible to the second thread. But since that should basically be the same connection to PgSQL (should it?) I hope there is a way to share this transaction scope so my second thread can access data being added within it?..

Any idea?

Database is PgSQL 8.3, driver is postgresql_psycopg2. Django — trunk.

+3  A: 

I'd say that's impossible. To my knowledge, each thread has its own PostgreSQL session to be able to run concurrently. And given that PostgreSQL is an MVCC database, one thread will not have access to the other's changes, until the transaction is committed – which it won't be in the case of a Django 1.1 TestCase.

If you need to test stuff that runs concurrently, I'm pretty sure that you need to use a TransactionTestCase.

mikl
TransactionTestCase is killing me — for some reason TRUNCATE is taking *forever* to complete...
Yurii Rashkovskii
Have you checked if the second thread has been stopped before the test ends? It might cause the truncation to run a lot more slowly, since per MVCC, PostgreSQL has to store a copy of the truncated data.
mikl
hm, that's interesting.. the whole idea was not to stop background thread throughout all tests lifetime. in this case I might just consider starting and stopping 2nd thread in each setUp and tearDown, respectively.
Yurii Rashkovskii
I think you are correct when it comes to using setUp and tearDown, but it depends a bit on the nature of your test. Generally, for the tests to be atomic, both threads would have to work on the same dataset, and starting a new thread for each test would probably be the most clean way to ensure that.
mikl
yeah, I thought about it before — just was sort of concerned that at some point 2nd thread startup might be not instant ;)
Yurii Rashkovskii
Yeah, well. Testing is slow, but then you have an excuse for hallway swordfights: http://xkcd.com/303/ :)
mikl