Crackpot Idea for Core Data Multi-User Document
nerkles August 5th, 2005
I’m still a bit new to Cocoa and Objective-C, but not to programming in general.
I’ve been grappling with a way to use all the goodness and time-savingness of Apple’s new Core Data such that multiple users can access the same data but not mess each other up. I have no idea if this would work. But I’ve done quite a lot of digging and the consensus seems to be that this is impossible, and it would be much easier to settle for FileMaker 7, or maybe Servoy or 4D.
From what I’ve read on various listservs and forums, it seems that it’s safe for multiple users to access the same Core Data document over AFP (assuming it’s stored in SQLite format), and it’s quite unlikely to get corrupted. The problem is that no notifications are sent, so if User A and User B are both editing the same Object, you could run into trouble: they can overwrite each others’ changes and that makes the data unreliable.
My crackpot idea for a potential way around this problem is that the Client app has to log in to a Coordinator server. Any time a user starts editing an object, the client sends a notification to the Coordinator, which quickly tells all the other Clients to lock their user from editing that particular object. When the edit (or creation of a new object) is complete, client tells Coordinator, which tells the other clients to refresh their copy of that object. This might require the use of an “Edit” button similar to how Apple’s Address Book works.
The client app has to be responsible for sending some kind of “hey, I’m editing this object” message to the Coordinator before letting the user finalize a change, and it has to quickly mark an entire object uneditable when it receives a notification from the Coordinator (which means each client is running a server thread to listen for these).
Here’s a rough diagram:
That’s the basic idea. So am I nuts? Is this just too impossibly complex, is it even possible, is there a better way?
I was also kicking around the possibility of the Client apps coordinating themselves, by way of Bonjour. But that means you couldn’t run this across the Internet, only on a LAN (which may be OK for most cases, and there is always VPN).
Anybody want to work together on an open source proof of concept?
http://www.apple.com/webobjects/
Hi Web Objects,
I like the idea of WO, and it’s clearly a powerful system. However, part of my reason for pursuing this is I need an app that can integrate with the standard Apple apps like Mail and Address Book. Short of some kind of crazy browser plug-in, I don’t think it’s possible with a web app. Right?
Hi
I have not been able to spend the time with core data that I wanted to, but I have also thought about what would be the best way to achieve a client server setup with core data. It seems to me that what would be needed is some kind of server/deamon app to be written that would use core data to create a MO context for each connection. The client app could then use Distributed Objects or some other suitable mechanism to treat that server side MO context as it’s datasource for its own local core data stack. Can you do nested MO contexts the way you could do nested EOF editing contexts? If DO worked, would the client app even need a core data stack? Might only need the proxy for the remote MOcontext.
I think that this is sorta like the arrangement used in the WO/EOF Java Client app arrangement. I think that if you looked at how that was setup you could get some ideas. Bury all actual file access in your coordinator app and have the clients connect to it, not the file.
(fancy DO example here: http://homepage.mac.com/azc/DistributedWidgets/)
I just thought of the most obvious thing. Could it be this easy? Use Distributed Objects to “vend” the ManagedObjectContext? One instance of the app with access to the data store could vend, while the others use a vended MOC?
Well, that would sure simplify things. I won’t have time to try it for a couple weeks, but if anyone knows whether this is even possible, it’d be good to know.
Hi I spent a little time looking at this problem this weekend, but i couldn’t get it working and obviously have alot more to learn – however;
It seems to me that the proper object to vend is the Persisent Store Coordinator. Multiple MOCs can use one PSC, but each client will need it’s own MOC. Also there is probably alot of messaging that takes place between the MOC and the UI widgets because of the observing stuff that would clog up the network.
JS– Thanks for trying that out! When I have time to mess with this, I’d like to try it both ways. I think for my case the network traffic wouldn’t be so bad since there will be < 20 users.
Hi! I am very interested an looking for a solution to the problem of multiple users on different computers accessing the same data using core data… I have made some tests with the SQLite storeType, specifying the mergePolicy in the managedObjectContext to NSRollbackMergePolicy and allowing to the application’s user to do a commitEditing and a save against the context every time it is necessary… With this configuration i can see that, at least on my tests, the data is not corrupted during simultaneous operations of two application instances…. but also is hard to keep synchronized the two applications… the fetch recovers the new objects, added from the other running instance, but don’t recover the changes done in one of the existing and previously added ones… The idea of a coordinator server is not bad… but a think that is going to make the things very complicated in comparison… Somebody has some kind of little example already running??? And another completely different question…. what i should do to become a member or to enter to the mailing lists published in cocoabuilder? I can’t find that info, and the “terms of use” at the bottom of each page doesn’t seem to work…
I finish publishing some information related to coreData and a multi-user application in gustavovera.blogspot.com. Regards.
Hello –
Did you every have any success with using Distributed Objects to vend out an NSPersistentStoreCoordinator? I too am looking to do the same thing. I’ve exprimented, but I can’t get it to work. I’m able to get the PSC in my client app, but it seems that its coming over as a DO proxy object – I think this is causing a problem in the Core Data system somewhere, but I’m not sure.
Hey Jeremy,
I’ve been too busy, haven’t tried it yet. I’ll definitely post when I do. I just got my hands on Advanced Mac OS X Programming from Big Nerd Ranch, which claims to have some secret about getting Distributed Objects to work right. So we shall see!
Please drop me a line if you make any progress before I do. [nerkles at "gmail" d0t c0m].
Did the Advanced Mac OS X Programming book provide any insight into this issue? Just curious…
I have to admit I got the book but haven’t dug into it. I’ve concluded, at least for now, that Cocoa + Core Data is not the right approach for the project I’m working on, although this Coordinator model might actually work if somebody had time to try it and refine it.
I’ve decided that TurboGears is the way to go for this project (when they release 0.9 or 1.0) because part of the spec is that it’s going to have frequent changes to the GUI. That’s going to get too crazy… creating and deploying a new build every few weeks. Better to centralize all that implementation on the server and have “instant” deployment to the browser.
It means a slight compromise on the speed of updates to each user’s View, but AJAX will keep that problem to a minimum. I’ll just have to ensure only one user at a time can edit each object. It may even end up using a similar Coordinator pattern, but with AJAX, and the web server handling that coordination.
Feel free to pursue the idea though… Drop me a line if you get anywhere with it, I’d like to know it was helpful or not.