On Nov 29, 2007, at 6:14 PM, Chris Withers wrote:
> > Hi All, > > I'm a real newbie when it comes to SQL Alchemy and I'm curious to know > what happens when another process changes the relational data that the > object model is built from? How is the object model invalidated such > that it is updated in this case? > SQLAlchemy doesn't have any communication lines between two different Sessions, other than the database itself. Objects stored within a Session are only invalidated when its told to do so, or when an object falls out of scope within the application. The Session has the ability to invalidate its entire contents, individual objects, or individual attributes on objects. There is also a method available on the Query object to unconditionally overwrite objects as it loads them (populate_existing()). Automatic invalidation of objects based on events is usually the job for a long running cache of mostly read-only objects. While the Session is somewhat cachelike it is more analgous to a transaction- scoped cache. The underlying transaction in use will determine most of the session's behavior when loading in entities, making changes, and commiting them. In most transaction isolation modes, the rows that you've loaded into the transaction normally don't change until the transaction is complete; otherwise your application could be making decisions against data which suddenly changes mid-transaction. The Session generally behaves along these lines, especially if you use the "transactional=True" flag which means it will always be inside a transaction; after a commit or rollback a new transaction is started on the next database access. The usual approach to concurrency is to keep individual Sessions relatively short-lived and focused to an individual series of operations; since most people are building web applcations, a single web request usually defines the boundaries for a particular Session. We also define some methods for dealing with concurrency more explicitly; one is optimistic locking by using a version id column (this is the version_id_col keyword argument on mapper()), and the other is pessimistic locking which locks rows using an approach centered around SELECT..FOR UPDATE (this is the query.with_lockmode() method). as the names imply, optimistic assumes nothing will usually go wrong but raises an error when its detected that its updated stale data; pessimistic locks rows at the database level and prevents concurrent operations from happening, but then has all the fun side effects of aggressive locking like reduced application performance and greater potential for deadlocks (if its overused). As a point of reference the Session methodology we use is tailored to be similar to that of Hibernate, which we chose because its a widely used and proven model, and also very easy to understand since its generally pretty hands-off, with no behind the scenes magic to confuse the issue. Hibernate's documentation has a long chapter on this at http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html ; most of the conceptual content here applies to SQLAlchemy as well. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
