Re: MATREADU/MATWRITE statements timing out

On Nov 26, 12:16 pm, "Excalibur" <excalibu...@xxxxxxxxxxx> wrote:
<big snip>>> Peter,

General rules are :

Pessimistic locks for transactions (required for transaction
boundaries anyway)
Optimistic locks for "masterfile updates" (which 'deteriorate' to
field by field comparisons during actual update, when a Pessimitic
locks is exterted whilst the actual update/comparison is done)

Hi Ross
Thanks for the response
Are you confirming that the user returns an original unaltered copy and an
altered copy?
That a comparison of original to file copy then takes place and the update
only continues if all is equal.
All updates are done on a field by field comparison.
Seems like there must be better ways to me. One way I have considered is to
issue an update token and only continue if it has not expired for this
record ie a new one has not been issued for the same record.
Regards
Peter McMurray



Peter,

The actual implementation may vary - I can not talk for "everyone",
but with Visage, as we only transmit fields that have changed on the
client in the first place, the amount of traffic on your comms line is
reduced to a minimum anyway - and the "old" copy of the record is held
on the server anyway, so not much more traffic on the line than you
may have now (indeed, would be far fewer packets flying around if
comparing to a green screen, where each keypress is going to generate
a round trip, 1 byte packet to collide with everything else on the
network :-)

If you look at "reality" again, in most instances the amount of work
involved for the comparison is "trivial", and far outweighs the
benefit of someone in the back office being able to update a customers
address, while someone at front office is recording a new phone number
because they are on the phone.

The notion of update tokens will still provide the same level of
"lockout" (or frustration if they are issued to "anyone", making prior
tokens invalid, or locking people out if a timeout) as a REAL record
lock, as will Kevins suggestion of an arbitrary timeout - even if this
is 5 minutes, users will be "upset" for > 2 minutes on average when a
situation like this occurs.

Mechanisms like this have grown up to address real world situations -
and the "bigger" your world, the more useful it becomes.

However, we recognised that one size doesn't always fit all, which is
why Visage allows you to use real live READU's (allowing it to work
alongside your unaltered green screen code), field level optimistic
locking, and also Visage "native" locking if we don't have to worry
about green screen clients. If your app grows & gets into an
environment where you NEED optimistic locking at the field level, just
flick a configuration parameter & you are done.
.

Relevant Pages

  • Re: [PATCH 0/3] 64-bit futexes: Intro
    ... i suspect _any_ abstract locking functionality around a data structure ... tightly coupled to the exact details of which atomics are fast on a ... For example, some loads are almost entirely read-read locks, with only ... There we can just do a write to unlock. ...
    (Linux-Kernel)
  • Re: Transaction Isolation Level
    ... what size servers are you working ... and only have to specify locking hints when we ... need locks. ...
    (microsoft.public.sqlserver.server)
  • Re: row vs page locking...
    ... so they automatically escalate to page level locks. ... 'Lock Escalation' - see Books Online. ... SQL Server 2005 is going to have a Snapshot ... Good old fashioned locking is less sexy, but I find, more productive! ...
    (microsoft.public.sqlserver.server)
  • Re: MATREADU/MATWRITE statements timing out
    ... Locking of transaction records (as ... If I take a typical debtor master file I can be ... Pessimistic locks for transactions (required for transaction ...
    (comp.databases.pick)