Re: Multi-User using Core Data?
Re: Multi-User using Core Data?
- Subject: Re: Multi-User using Core Data?
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 11 Jun 2005 22:46:27 -0700
On Jun 11, 2005, at 7:27 PM, mmalcolm crawford wrote:
Returning to the original topic of this thread, since you seem to
know something about how this works, can you explain what CoreData
does about implementing it's locking on the SQLite files with a
view to understanding network sharing? SQLite has Shared-
>Reserved->Pending->Exclusive locks and on Unix like machines
these are typically implemented using Posix advisory locks.
Advisory locks have been buggy on NFS for years; if AFP reliably
implements networked locking then things _should_ work if you
simply point multiple programs on multiple machines at a shared
copy of the file.
Bill would be better able to comment on the file-level locking
issues here. In general, however, Core Data (as EOF) uses
optimistic locking to ensure that two users do not overwrite the
same data. This does not rely on file (or row) locking...
Sure. Off the cuff answer below. First, from a pure SQLite
perspective:
Of note, all locking in SQLite is performed on the entire database.
On filesystems that support POSIX advisory locks, SQLite uses the
same exact locking mechanisms as it would if you were to build the
stock SQLite.
For AFP, SQLite uses byte range locks to simulate a locking behavior
that is as close to advisory locks as you can get without having true
advisory locks. The only difference is that you might see a
situation where what should be a shared lock appears as an exclusive
to another process or connection. Given that your code should be
dealing with this situation anyway -- what if some random process
should grab the database and do something to tables you have no
control over? -- this should not pose a huge problem.
For NFS, SQLite will test to make sure that advisory locks really
work. If they do, they are used. If not, .lock files are used.
For SMB (Samba), SQLite will use flock() style locks. Since there
is no way to upgrade a shared flock() lock to an exclusive flock()
lock without offering a window of time within which another app can
effectively 'steal' the lock, flock() based locks will only support
exclusive locks.
Note that NFS does not fall back to flock() if advisory locks do not
work. Testing revealed that this was the safe way to go.
Note that mixing file systems when accessing a single SQLite database
file is a really, really bad idea. The alternative was to basically
go with .lock files on all filesystems.
All SQLite unit tests passed except those that should fail when
shared locks are not available.
The API for the additional locking support is at the end of
sqlite3.h. The underlying changes will be posted back to the SQLite
development community as time permits. Now that WWDC is over, time
is much more permissive...
---
What does this mean for Core Data?
Core Data does not keep SQLite connections open for any longer than
is necessary to perform a particular operation. While any given
transaction may be relatively involved-- may use a number of SQL
statements in its internal implementation -- Core Data will have
closed all transactions before returning control to your code (or the
main-event-loop, in the case of pure bindings based apps).
In other words, if you are doing a complex, large scale, fetch in one
process using Core Data, it will block other processes and will
sometimes do so more than others, depending on filesystem. However,
this situation should occur fairly rarely.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden