Hi! On 2010/09/24, at 19:26, Alan Ward wrote:
> Interesting. I've never really thought about it that way. I've always > considered it to be a way to find out if something > outside of my app instance changed the data underneath me. If you think > about it like that then it works perfectly. > Inside my app instance I like to think that I know what's going on and don't > need any help from Optimistic Locking > but maybe I'm crazy. You're not crazy, you actually HAVE to do that if you want concurrent stuff to work fine inside the same instance (by the means of locking the OSC or any other way that isolates the critical section). The point is: if you already wrote code to handle OL problems between different instances (assuming you did), why do you have to write more code (and debug it, which is hard with concurrency stuff) to solve *the same problem*, this time inside the same instance? It should work exactly in the same way: the DB row should be compared to the original data you got ON THAT EC. I believe Core Data has a row snapshot per EC (or their equivalent), which solves the issue. I believe WO should have that too. :) Regards, Miguel Arroz _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
