On Tue, 2007-06-19 at 11:51 -0700, Gerry Snyder wrote: > Michael Hooker wrote: > > Many thanks for the explanation Dan. > Ditto the thanks. > > I suspected the purpose of ROLLBACK was as you say, but couldn't see > > why it was used here. You point out the "under the hood" difference > > between ROLLBACK and COMMIT, but what about END? My main (third-party, > > commercial) application may well have some data stored waiting to be > > fed into the database after the file has been copied, and if it is > > forced to discard its cache that presumably means these are lost, > > which wouldn't be a good idea.
END is the same as COMMIT in sqlite. > It shouldn't have to. The cache Dan was referring to was an internal > copy of (part of) what is already in the data base. If the data base > file has been updated, that copy has to be discarded, since it may not > be valid--of course, it may be valid, but figuring out whether it is > would be a lot more work than just rereading it. Anyhow, this is all > happening at a much lower level than the application data you are > referring to, which is still valid and should be entered into the file. Right. If another app has some "writes" (dirty pages) in it's cache, then it will already have at least a RESERVED lock on the database file. If this is the case the "BEGIN IMMEDIATE" statement executed by the copy-file process will fail to obtain it's EXCLUSIVE database lock. So the only logic the file-copy process needs is "Do not do the file copy until after the BEGIN IMMEDIATE succeeds". Dan. > HTH, > > Gerry > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
