Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses?
The problem being "if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once". An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. We ran into this while modernizing US Food's internal "system of everything" from COBOL to something else. I'd expect this issue to be of core importance to any multi user or multi homed database. Just curious. Thanks. On Oct 8, 2012, at 11:40 AM, Flavio Donadio wrote: > Hello, all! > > > This a follow-up to a thread started last July. I looked into a lot of > things, tested some crazy ideas (that went wrong) and came to my final > decision for my project. I consider it very important to let people know what > I decided. Maybe I can help someone. And, for sure, you guys can warn me if > I'm making the wrong decision. > > I can say, for sure, that sharing the SQLite database is a bad idea if you > have a busy and slow network. The Distributed Objects idea is not so bad, but > gives a lot of headaches: the implementation of your "business-logic" ends up > being composed of 90% error handling code. > > I also dismissed the "real-time updates" idea. The user will have to refresh > the view manually. It saves a lot of effort and users will not get confused > by table views changing unexpectedly, for example. > > So, for the back-end (server side), I'll be using WebObjects to develop a > RESTful web service. I chose WebObjects because it's proven, it works very > well (Apple uses it on their app stores and iTunes) and it uses a language > that is kind of familiar to me (being used to PHP and a couple of C > variants). Also, the framework's design patterns are very similar to Cocoa. > The development tools are good enough and try to mimic the old tools that > Apple provided. It can be deployed on Mac OS X, Linux and others, using > standard Java application servers. The WO community seems to be very strong, > united and helpful (just check how busy the webobjects-dev list is today). > > Another reason why I chose this over TouchDB or protocols like SPDY and BLiP, > is that I can use a RESTful service with anything. In the future, I could > develop clients for different platforms. And WebObjects helps a lot when > creating HTML-based interfaces. > > I looked into Ruby on Rails as an option, but since the Ruby language is very > different from everything I know, I chose not to go that route. > > For the front-end, I'll develop a Cocoa client using ActiveResourceKit > (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, > it's the most straight forward to use, and the most feature-complete > framework for consuming RESTful web services. > > I also looked into AFIncrementalStore and RESTKit. > > Kudos to Steve Steinitz, Jens Alfke, Chris Hanson and Alexander Spohr for the > tips. > > > Cheers, > Flavio > > On 18/07/2012, at 16:00, Flavio Donadio wrote: > >> Steve, >> >> >> I agree with Apple, SQLite, you and every other sensible developer out >> there: I won't try this! :) >> >> >> Cheers, >> Flavio >> >> On 18/07/2012, at 04:49, Steve Steinitz wrote: >> >>> Hi Flavio, >>> >>> While Apple, SQLite, myself and any sensible software developer advise >>> against it, Core Data can run multi-user by placing the database on a >>> server which supports AFP (e.g. a fast Synology NAS over gigabit ethernet). >>> >>> SQLite has limited optimistic locking support, but the record locking will >>> only work over AFP. >>> >>> As mentioned elsewhere, you still have the (big) problem of keeping the >>> cached objects of each Mac up to date. We do it by getting fresh data from >>> the database, then saving, every minute (plus or minus random seconds) >>> during idle time. The "refresh" code is complicated, ugly and big -- with >>> bad smells abounding. >>> >>> To make it work at all in Leopard and beyond (when Apple finally put their >>> foot down on this abomination) you need to set a special Apple SQL pragma >>> when creating your persistent store. Our line of code looks like this: >>> >>> [pragmaOptions setObject: [NSNull null] forKey: @"lock_proxy_file"]; >>> >>> A retailer has been doing this for their Point of Sale (and back-office) on >>> seven Macs for six years. We lost a little data a couple times in the >>> early days and we occasionally get a glitch under heavy Saturday load, but >>> we've tamed the beast and now it works surprisingly well -- and fast. >>> >>> Be warned that there are, as Ben Trumbull once colorfully observed, "sharp >>> edges". >>> >>> Cheers, >>> >>> Steve > > > _______________________________________________ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
