Re: For Tom Lane

On Fri, 2005-05-27 at 09:57, rubensoda(at)inwind(dot)it wrote:

>
> Thanks for answer Tom
>
> "Consider what happens when the user leaves for lunch"
>
> Well, I've already thought about it.But I'm working with
> VS2003 and disconnected dataset.. so when user edit data
> he's modifying an "old" disconnected row, while real updated row
> is in the database..
> So my strategy would be (as I already written):
>
> 1. refresh data recalling current row from database to the form's fields
> 2. lock the row
> 3. update modified data in the database through stored procedure (function)
> 4. commit and unlock the row
>
> Have you another idea that could work better with disconnected objects ?

While this ensures that the update is atomic, it doesn't ensure that no
one else is trying to edit it at the same time.

What you might want to do is either optimistically lock it, or use
application level locking. To use optimistic locking, you'll need to do
something like make an md5 of all the fields being edited, then, right
before you write back the data, check to see if the md5 you created at
the beginning still matches by re-reading the data and md5ing it again.
If it doesn't match, then you can throw a "mid air collision" error, so
to speak, and tell them that the record changed underneath them, or do
some kind of merging / or whatnot.

If you want to do application level locking, then create a field and use
that for locks. Just make it a timestamp field and put in the current
time value when the lock is taken. When the predetermined timeout
occurs, the user lock is removed by the next person to access it, or
offer them chance to, or email the original locker, etc... Handle it
the way you want or need to.

"Scott Marlowe" <smarlowe(at)g2switchworks(dot)com> wrote in message
news:1117557422(dot)20484(dot)35(dot)camel(at)state(dot)g2switchworks(dot)com(dot)(dot)(dot)
> On Fri, 2005-05-27 at 09:57, rubensoda(at)inwind(dot)it wrote:
>
>>
>> Thanks for answer Tom
>>
>> "Consider what happens when the user leaves for lunch"
>>
>> Well, I've already thought about it.But I'm working with
>> VS2003 and disconnected dataset.. so when user edit data
>> he's modifying an "old" disconnected row, while real updated row
>> is in the database..
>> So my strategy would be (as I already written):
>>
>> 1. refresh data recalling current row from database to the form's fields
>> 2. lock the row
>> 3. update modified data in the database through stored procedure
>> (function)
>> 4. commit and unlock the row
>>
>> Have you another idea that could work better with disconnected objects ?
>
> While this ensures that the update is atomic, it doesn't ensure that no
> one else is trying to edit it at the same time.
>
> What you might want to do is either optimistically lock it, or use
> application level locking. To use optimistic locking, you'll need to do
> something like make an md5 of all the fields being edited, then, right
> before you write back the data, check to see if the md5 you created at
> the beginning still matches by re-reading the data and md5ing it again.
> If it doesn't match, then you can throw a "mid air collision" error, so
> to speak, and tell them that the record changed underneath them, or do
> some kind of merging / or whatnot.

The ODBC driver uses the ctid value to check whether a record has changed;
an updated row will always have a new ctid. That would probably be the most
economical way to check.

>
> If you want to do application level locking, then create a field and use
> that for locks. Just make it a timestamp field and put in the current
> time value when the lock is taken. When the predetermined timeout
> occurs, the user lock is removed by the next person to access it, or
> offer them chance to, or email the original locker, etc... Handle it
> the way you want or need to.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>