On Aug 7, 2010, at 8:43 AM, Brad Gibbs wrote: > I've been developing an app meant to run strictly on a local network. I'd > like to have the capacity to run 50 clients and a single server (although > most installations will have fewer than 20 clients). My plan has been to > have each client maintain its own Core Data database and sync with the Core > Data db on the server. I've been using BLIP to message over TCP.
Yes, that's fine. The problem is trying to share the db file directly via a network file system. The network file systems are not designed to keep the client machine's OS caches coherent in real time. - Ben > > Communication should work like this: > > 1. Client sends command to server > 2. Server updates its CD db > 3. On a didSave notification, server messages changes to all connected > clients > 4. Connected clients receive the update message and update their db's > accordingly > 5. If a client is offline for a period of time, when it rejoins the network, > it asks the server for a batch update (I haven't decided whether this will > request the entire data file as it stands at that moment, or just ask for > incremental changes since the client's last save, but I'm leaning towards > re-sending the entire db, which is typically smaller than 1 MB) > > In my app, objects are infrequently being created and destroyed. The changes > are primarily just attributes of existing objects being updated. > > I don't believe this runs afoul of the patterns Ben is describing, does it? > I'm not sharing the Core Data db, I'm just keeping several Core Data db's in > sync by providing methods on the server that each client can call remotely. > > Also, I attended a session at WWDC this year that describes extending Core > Data for use in a multi-user environment. I'd have to watch the video again > to get the specifics, but, I think the gist of it was to keep a local copy of > the data and sync with the server. > > I hope rampant speculation about an unannounced OS doesn't run afoul of any > NDAs, but, I've got to believe that Apple is working on extending Core Data > for use in a multi-user environment. With iPhone, iPad and desktop users and > Apple's recent push into SMB, accessing a central database from each of these > devices via Core Data just makes too much sense. Maybe it isn't exactly Core > Data and maybe it's some tie-in to FileMaker, but, I've got to believe it's a > priority for them. It's just too big of a nut to ignore. > > > Brad > > > > On Aug 6, 2010, at 11:38 PM, Ben Trumbull wrote: > >>> Can more than one process be accessing the same Core Data sqlite file? >>> >>> This post from author Marcus Zarra says "no"∑ >>> >>> http://forums.pragprog.com/forums/90/topics/1476 >>> >>> But this post from Ben Trumbull seems to say "yes", as long as the two >>> processes are accessing it via the same filesystem: >>> >>> http://www.cocoabuilder.com/archive/cocoa/184606-core-data-file-sharing-via-an-afp-alias.html >>> >>> Which one am I misunderstanding? >> >> There is a big difference between multiple processes accessing the same Core >> Data file and multiple machines. Multiple processes on the same local >> machine work fine. Several Apple products do this. Multiple processes >> across multiple physical machines will not work well (AFP) or at all (NFS). >> >> So we don't recommend targeting a multi-user configuration. As I mentioned >> in that earlier post, your best bet is probably write the proper service >> that uses Core Data, and vends to your client processes via IPC (like a web >> service). The client processes might independently use Core Data for local >> caching (replication). >> >> It possible, but inefficient, for a very limited number of clients to share >> over AFP. NFS doesn't work correctly at all. This is restricted by file >> caching issues underneath us. There are a lot of limitations and sharp >> edges here, so we actively recommend against multiple computers >> simultaneously accessing the same db. Support for it is disabled by default >> for projects built with a deployment target >= 10.6 >> >> - Ben >> >> _______________________________________________ >> >> 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: >> http://lists.apple.com/mailman/options/cocoa-dev/bradgibbs%40mac.com >> >> This email sent to bradgi...@mac.com > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
