The method that works 95% of the time is, just establish a connection to the
database, start a transaction, do some work that stays within the thread,
commit the transaction. Then throw all loaded state in that thread away, and
reload it all on the next transaction.
Its only if you
it really is that - simultaneous transactions are isolated from one another,
and their results are only made visible to other transactions after they're
committed. as far as locking, you generally choose between an optimistic
and a pessimistic approach:
Thanks.
Ok, so I found an article
Basic question:
I have 1 app with multiple processes and threads. Each thread
and/or process may end up trying to do something to the database at the
same time. What is the solution to threading? How do web frameworks
solve it? Is there some inherent design in databases and/or SQLAlchemy
On Dec 17, 2009, at 8:56 PM, Kevin Ar18 wrote:
* If I setup 2 sessions, that means I will have 2 connections to the
database, meaning the database is the one that will handle threading
conflicts per what is described here:
http://www.postgresql.org/docs/8.4/static/mvcc.html
So, I have 1
