Re: CoreData vs. SQLite for Multi-User Simultaneous Access
Re: CoreData vs. SQLite for Multi-User Simultaneous Access
- Subject: Re: CoreData vs. SQLite for Multi-User Simultaneous Access
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 17 May 2006 19:12:56 -0700
On May 17, 2006, at 6:41 PM, Robert Sesek wrote:
1) Will this actually work if I stick with my SQLite static-library
backend? Can multiple users access my single database file
simultaneously and add/update rows without problems (as long as I
refresh my NSTableView every so often)?
It depends entirely on the network filesystem that you are using. If
it supports **working** unix advisory locks, then there is a good
chance that this will work correctly.
Note that a number NFS servers lie about their support of advisory
locks, happily returning "file locked successfully" even when someone
else already [thinks they] has the lock.
2) Could I switch to using CoreData and still keep a simultaneous
multi-user environment? I don't think I'll switch to CoreData, but I
would like to know if CoreData can handle that for future projects.
The SQLite in Tiger handles network file systems. For AFP, it uses
byte range locks to implement a locking semantic similar to that of
local advisory locks. For NFS and SMB, it falls back to .lock
files. Slow as heck, but at least it works.
However, neither Core Data nor SQLite solve the problem you really
have. You need a client/server database access semantic. Relying on
a network filesystem is ultimately going to prove to be a nightmare --
it'll either corrupt your data or be too darned slow to be usable by
multiple users.
When faced with such problems, I have looked to using a client/server
layer to store the data in a central server while my client side code
populates a Core Data in memory store. This gives me all the
freebies of programming Cocoa with Core Data while also allowing me to
use a proper client/server protocol to communicate to a server that is
designed around multi-user access.
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