On 09/10/2012, at 01:46, z...@mac.com wrote: > For 2. Can you use a NSNotification to fire and forget an unlock event?
Not really. The server can't send the notification back to the client. There's a RESTful web service between the client and the database. > But are you merely querying the database, or do you have a facility to send > messages back to the GUI? I'm querying the database only. I still can have the client poll the app server with a fair interval, but this can create overhead as more clients are added. I don't like polling at all... > If there are messages back so, you can set up a message relayer that can hold > the current messages from the server and choose how to or when to relay them. It would require something else for the client-server communication, like the protocols Jens Alfke suggested. Or talking to the database server directly, with something like BaseTen (only for PostgreSQL). Or going low-level (e.g., libpq), which goes beyond my skills. Since I am not a dev-wizard like you guys, I have to stick to simple things! ;) Also, keep in mind this is an in-house project, never meant to be a commercial product. We can deal with some problems in ways that would not be desirable in commercial software. But, since I'm a Mac user, I want things to be as perfect as they can be.... Cheers, Flavio > ------Original Message------ > From: Flavio Donadio > To: Alex Zavatone > Cc: Cocoa List > Subject: Re: Core Data Multiuser > Sent: Oct 8, 2012 11:54 PM > > On 08/10/2012, at 17:56, Alex Zavatone wrote: > >> 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. > > I don't think I'll have performance problems. I'll never have more than, say, > 20 users at any given time and these "race conditions" will be rare. The > database server can handle this easily, *in my case*. The real problem is in > the user interface. > > The interface will be like in Address Book: the user opens a card/record for > viewing, but has to click an "Edit" button to make changes. If the record is > locked, the user will get an alert when he/she clicks the button. I need: > > 1. A mechanism to avoid users opening records for editing and leaving them > open "forever" (timer?); > > 2. Some kind of feedback for the users when a record is unlocked, without > having to refresh manually. > > Ideas are very welcome. > > > Cheers, > Flavio _______________________________________________ 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
