Re: Core Data Multiuser
Re: Core Data Multiuser
- Subject: Re: Core Data Multiuser
- From: Flavio Donadio <email@hidden>
- Date: Tue, 09 Oct 2012 11:42:36 -0300
On 09/10/2012, at 01:46, email@hidden 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 (email@hidden)
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:
This email sent to email@hidden