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.
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
