> On 13 Apr 2015, at 17:10, Jens Alfke <j...@mooseyard.com> wrote:
>
>
>> On Apr 13, 2015, at 7:01 AM, Mike Abdullah <mabdul...@karelia.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
