Re: Core Data Multiuser
Re: Core Data Multiuser
- Subject: Re: Core Data Multiuser
- From: Alex Zavatone <email@hidden>
- Date: Tue, 09 Oct 2012 11:10:09 -0400
On Oct 9, 2012, at 10:42 AM, Flavio Donadio wrote:
> 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...
Yeah, I agree 100%
>
>
>> 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....
I'm not a dev wizard either, but based on my experience in the late '90s and early 2000s writing a few things, I can see these few items that might bit you in unpleasant ways.
1. Multiple people trying to write to the same item. Maybe spend time to come up with an access model that grants privs based on who is accessing what?
2. Timeouts. What happens when a user has opened a record (and thereby locked a record) and their machine loses power or connectivity? How will you handle this?
It's possible to write a timestamp based on GMT for when the record edit was initiated. Before displaying that record from the DB, check it and if it's > than your timeout value then reset the lock on the item.
3. If you want to have your GUI respond to changes in the DB, and you have no method to yap back to the GUI, then seems like you're going to have to poll.
You might want to consider how to make the basic design work, then plan on ways that you can see that it will break. You've already outlined a few of them. Though you hate polling (I mostly agree), you can implement something better, a heartbeat, where when you initiate part of your GUI, you issue a request to happen in the future where you check "Am I still using this thing?" If so, update the time to check again and continue for another. If you're not, immediately write the change, lock the record and dismiss the heartbeat. It's polling yeah, but I'm trying to position it differently and it would only run when you have your edit button clicked.
If there is no way to read back and forth from the server, then you're going to have to poll, or write to the database to use the database to be a state engine for the requests going to the database. Seems UBER sketchy when it seems like proper timestamping of request issues and sparse polling will do the trick.
GL. I'm interested in seeing how this works out
>
> 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