|
|
Posted by Rik on 05/19/06 22:27
Jerry Stuckle wrote:
> rich wrote:
>> I am building an app using php and postgresql. My questionis this.
>> How do you handle people wanting to make parallel changes to a
>> record.
>> Since in web apps you are doing a select, bring over a record then
>> updating it, there is no lock on that record while you are making the
>> changes in your browser window. Does transactions handle that? Do
>> you
>> make your selection and update all part of the same transaction?
>> This
>> whole scenario has me stumped.
>>
>
> Keep the original values. Before updating, read the record in again
> and compare the values to the old ones. If they don't match, put the
> window back up with the new values and tell the user.
>
> You can also be a little more creative. Check the columns which are
> being updated. If they haven't changed (but perhaps others have), go
> ahead and allow the update to the changed columns. However, if one
> or more columns have been changed, send a message back to the user
> with the new values from the database.
>
> A lot of hassle, I know. However, you wouldn't want to lock the row
> anyway. What happens if someone displays the record then closes his
> browser? Now you have a locked recored which you can't unlock (until
> perhaps some timeout value expires).
And still, it's possible to check if the values are the same, someone
immediatlly thereafter changes the values, and only then your script has
reached the point of updating the values. So it's by no way fullproof. It
would have to happen in a very small timeframe though, and it't not very
likely to happen. Yet, given enough time and transactions, someday it might.
Then again, I haven't heard of a slim workable solution witthout that
weakness either.
Grtz,
--
Rik Wasmus
Navigation:
[Reply to this message]
|