Re: Crash when move open document based app file to trash
Re: Crash when move open document based app file to trash
- Subject: Re: Crash when move open document based app file to trash
- From: Jonathan Mitchell <email@hidden>
- Date: Mon, 13 Apr 2015 17:36:01 +0100
> On 13 Apr 2015, at 17:10, Jens Alfke <email@hidden> wrote:
>
>
>> On Apr 13, 2015, at 7:01 AM, Mike Abdullah <email@hidden> wrote:
>>
>> I’m not sure how careful that monitoring is, though, whether it happens continuously, or only at the moment the app or document regains focus.
>
> Even if it’s continuous, it can’t be continuous enough, since the OS is multithreaded. There’s always the possibility of a race condition where the app tries to access the file after it’s been moved but before the notification arrives. Therefore the app can’t rely on the notification as its only source of truth.
>
> Jonathan: Does the app enable SQLite’s WAL (write-ahead log)? If it does, it should be more resilient to its files being moved. The reason is that the non-WAL behavior creates and deletes temporary files during every transaction, which implies that SQLite has to know the correct path to the database at that time. In WAL mode, as far as I can tell, the side files are more persistent and don’t get created or deleted in the middle of use.
>
> (As a bonus, WAL mode is generally a lot faster too!)
WAL sounds like it might offer advantages (see https://www.sqlite.org/wal.html) but there are downsides too - listed below.
Of these lack of network support is probably the killer. But I will dig a bit deeper.
Thanks
J
But there are also disadvantages:
• WAL normally requires that the VFS support shared-memory primitives. (Exception: WAL without shared memory) The built-in unix and windows VFSes support this but third-party extension VFSes for custom operating systems might not.
• All processes using a database must be on the same host computer; WAL does not work over a network filesystem.
• Transactions that involve changes against multiple ATTACHed databases are atomic for each individual database, but are not atomic across all databases as a set.
• It is not possible to change the database page size after entering WAL mode, either on an empty database or by using VACUUM or by restoring from a backup using the backup API. You must be in a rollback journal mode to change the page size.
• It is not possible to open read-only WAL databases. The opening process must have write privileges for "-shm" wal-index shared memory file associated with the database, if that file exists, or else write access on the directory containing the database file if the "-shm" file does not exist.
• WAL might be very slightly slower (perhaps 1% or 2% slower) than the traditional rollback-journal approach in applications that do mostly reads and seldom write.
• There is an additional quasi-persistent "-wal" file and "-shm" shared memory file associated with each database, which can make SQLite less appealing for use as an application file-format.
• There is the extra operation of checkpointing which, though automatic by default, is still something that application developers need to be mindful of.
• WAL works best with smaller transactions. WAL does not work well for very large transactions. For transactions larger than about 100 megabytes, traditional rollback journal modes will likely be faster. For transactions in excess of a gigabyte, WAL mode may fail with an I/O or disk-full error. It is recommended that one of the rollback journal modes be used for transactions larger than a few dozen megabytes.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden