johnf wrote: > On Thursday 17 April 2008 09:27:56 am Carl Karsten wrote: >> Ed Leafe wrote: >>> On Apr 17, 2008, at 10:38 AM, Paul McNett wrote: >>>> Since nobody is using my app (yet) in a multiuser context (database >>>> is a >>>> sqlite db stored locally) I don't have a problem holding the >>>> transaction >>>> open forever. >>> It's really no different than a DB that begins a transaction >>> implicitly - they can be open for just as long. >>> >>> The difference here is that this is under developer control. Current >>> transaction behavior works as always; all that's changed is that you >>> can begin/commit/rollback from the UI, as you wanted to do. >> note: my use of "sure" means I have nothing to back this up with, so I >> could be completely wrong. >> >> I am very sure this is not the intended use of transactions, and so the db >> engines are not going to take this kind of use into account, and thus there >> can be significantly undesirable side effects. >> >> I am pretty sure the implicit transactions are 'scoped?" for a single >> .execute(), where if you start a transaction, touch the db (delete some >> records) there will be some sort of lock on 'stuff' (no clue exactly what) >> until the user clicks something and the transaction is committed or rolled >> back. >> >> I am pretty sure the lock will block even SELECT queries. which would be >> really bad. >> >> Carl K > Not sure about the sqlite but that's not the case for Postgres or MsSQL (in > the standard setup). Actual locks do not occur until the commit. And both > now have savepoints. When you rollback to a savepoint, changes made since > the savepoint are discarded but not the changes made before the savepoint. > And I believe with Postgres you can imbed a transaction within a transaction > (never used it). >
So other connections don't see the updates (INSERT, UPDATE, DELETE) until the commit? I was under the impression that once a transaction was started, a SELECT on "that data" would wait till the transaction was done so that the SELECT would return 'current' data, where current includes changes made after the transaction started. Maybe lock is the wrong term. blocking? Carl K _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
