Hi,
First of all, I am not sure concurrent is the right word here - english is my second lang.
Its basically sever users editing the same content
I am writing this system with offers and stuff...
The admin will add his own offers.....but users will be able to add offers as well....
Actually there are two issues here.
1. The admin will sometimes want to edit an users offer....but what if the user is editing in this same moment...
Maybe I should lock the offer somehow - but what exactly...because locking thing also mean it should be unlocked at some point- how...
Haven't done such a thing so far....If you can give me pointers to the logic will be great...
2. There should be an approve process - so that if a user add an offer it will be desplayed only after the admin said ok.
2.1 The difficult part is that once an offer is approved and displayed the user will want to update it - hence will be an approve process again.
But the offer that is already approved should still be displayed(hence make a copy of it....for the modified version.)
I think of solving this problem with making a copy of the already approved version - and keep track of them with child/parent id....
If you have comments any suggestions with maybe improving this solution will be great.
concurrent editing....several users edit same thing
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
This is a tricky problem, the easiest way is to divide it up into sections: if one section is changed while another section is being changed, it shouldn't affect each other.
MediaWiki handles edit conflicts (which is sort of what you where talking about) by giving the person who edited first priority. Two people retrieve the same page, person one edits it first, when person two tries to edit the page, they will be notified, and will have to merge the edits together (if they were in different sections, they don't affect each other and voila, concurrent editing)
If you want to create a "locking" system, have the admin add and remove locks at his own discretion: if the user grabbed the page while it wasn't locked, the admin locks it, and the user tries to submit, it will be denied, and the user gets a chance to save their edit. Once again, see Mediawiki. What you're describing is a lot like a wiki.
MediaWiki handles edit conflicts (which is sort of what you where talking about) by giving the person who edited first priority. Two people retrieve the same page, person one edits it first, when person two tries to edit the page, they will be notified, and will have to merge the edits together (if they were in different sections, they don't affect each other and voila, concurrent editing)
If you want to create a "locking" system, have the admin add and remove locks at his own discretion: if the user grabbed the page while it wasn't locked, the admin locks it, and the user tries to submit, it will be denied, and the user gets a chance to save their edit. Once again, see Mediawiki. What you're describing is a lot like a wiki.
I'm not sure what you're trying to do: just queue the edits, and then once approved display them. If the user wants to make another edit, queue that too.jmut wrote:2. There should be an approve process - so that if a user add an offer it will be desplayed only after the admin said ok.
2.1 The difficult part is that once an offer is approved and displayed the user will want to update it - hence will be an approve process again.
But the offer that is already approved should still be displayed(hence make a copy of it....for the modified version.)
I think of solving this problem with making a copy of the already approved version - and keep track of them with child/parent id....
If you have comments any suggestions with maybe improving this solution will be great.
Read up on Pessimistic versus Optimistic locking and decide which works better for you.
Generally speaking Optomistic locking is "easier" and often good enough. It you detect a "collision" one of the two people will have to redo their work, but you'll be aware there was a colission and the earlier's work won't be wiped out.
Pessimistic locking is rough in web apps as people often forget to release their locks, so you have to either add a time-out, or have some other mechanism. Pessmistic locking can also create deadlocks so read up on concurrency control first to understand lock ordering/escalation issues.
Generally speaking Optomistic locking is "easier" and often good enough. It you detect a "collision" one of the two people will have to redo their work, but you'll be aware there was a colission and the earlier's work won't be wiped out.
Pessimistic locking is rough in web apps as people often forget to release their locks, so you have to either add a time-out, or have some other mechanism. Pessmistic locking can also create deadlocks so read up on concurrency control first to understand lock ordering/escalation issues.