>> I forgot to mention that what I have in mind are not several instances of >> SQLAlchemy, but a single instance which would be part of something like >> an "application server". Then all client requests would be processed by >> one and the same instance of SQLAlchemy, running on the server side. >> >> In such an environment, where SQLAlchemy should "know" at runtime which >> objects are modified by other clients, it should be possible to >> automatically keep everything in sync, no? > > right, but your server probably uses multiple threads and/or child > processes, and the SA session is only intended to be used in one > thread at a time, so concurrency issues can still come up, and one > thread/process can change the database while another session is not > exactly in sync with that new data.
For such cases, <duck> Modeling </duck> provides a mechanism that "broadcasts" changes made by one "editing context" to all others upon committing. Maybe they could share code with SQLAlchemy? Personally, I agree with SGI that: "GUI tools should not mislead the user; they should display the current state of the system, even when changes to the system originate from outside of the tools themselves." (Citation from http://oss.sgi.com/projects/fam/). So imho the GUI of a database application should always reflect the current state of the data in the database. Without polling, of course. Not like e.g. this ยง$%&@! Windows "Explorer"... Unfortunately there seems to be no "standard" mechanism to register a client with the database itself for notification of any updates to records. Even the PostgreSQL-specific "listen" and "notify" commands require polling to retrieve the notification events as far as I understand from the documentation. I wonder whether PL/Python support in PostgreSQL would allow to implement something like such an asynchronous notification system... >>> without going back to the database to refetch the data, or by >>> pessimistically locking everything (which is not recommended). >> >> Why not recommended? In some cases, consistency is more important than >> performance... > > it depends on the needs of the specific application, but pessimistic > locking is usually overkill, complicated, and can lead to deadlocking > conditions. In case of the "naive" implementation mentioned, e.g. if someone opens a record for modification and then leaves the dialogbox open for the rest of the day, because (s)he gets distracted and forgets about it... > long running sessions (with corresponding long-running transactions) > are not recommended anyway. Hibernate has this to say on the subject > (http://www.hibernate.org/hib_docs/v3/reference/en/html/ > transactions.html#transactions-basics-apptx): Thanks for the link. >> But, between "knowing something about the theoretical basis" (what's a >> lock, what does rollback mean), and being able to actually implement an >> entire transaction manager "by hand" "from scratch", there's a H-U-G-E >> difference imho. Something like five years of CS studies and at least as >> much of actual practical experience I guess. > > well theres a third option to those methods which is to use known > design patterns. And a fourth (imho the most "Pythonic") option: Don't re-invent your own nuts and bolts, use well implemented, tested and documented modules provided by third parties. :-) Sincerely, Wolfgang Keller -- My email-address is correct. Do NOT remove ".nospam" to reply. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
