Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 14 of 14 total
Thread Lock record to prevent editing
Sun, Jun 4 2006 10:48 PMPermanent Link

"Robert"

"GregF" <footyfacts@yahoo.com> wrote in message
news:B1A06C3F-6AB7-4344-B78C-AAD3091D929A@news.elevatesoft.com...
>
>
> If A has already updated it prior to your update
> then that state exists, if you do your update
> before A then your state exists.
>

That is a very simplistic view. If I've been looking at credit records, and
past payment history, and miscellaneous other information on a customer, I'm
gathering a good part of that info in my brain. The relationships, etc. So I
want to browse that as a book: while I'm reading it, whether  I read it
sequentially or I jump to chapter 6 and then back to chapter 2, nobody
should be rewriting a chapter behind my back.

Or take the case of a doctor looking at a patient's records. Looks at
history of tests, interviews with the patient, goes back to history (or not)
etc. All of these pieces of information about the patient need to be locked
while the doctor is perusing them.

Robert

Mon, Jun 5 2006 10:28 PMPermanent Link

"GregF"

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message news:E90C0FB7-9683-43BB-A174-0EF8AD2FE8EF@news.elevatesoft.com...
>
> "GregF" <footyfacts@yahoo.com> wrote in message news:B1A06C3F-6AB7-4344-B78C-AAD3091D929A@news.elevatesoft.com...
>>
>>
>> If A has already updated it prior to your update
>> then that state exists, if you do your update
>> before A then your state exists.
>>
>
> That is a very simplistic view. If I've been looking at credit records, and past payment history, and miscellaneous other
> information on a customer, I'm gathering a good part of that info in my brain. The relationships, etc. So I want to browse that as
> a book: while I'm reading it, whether  I read it sequentially or I jump to chapter 6 and then back to chapter 2, nobody should be
> rewriting a chapter behind my back.
>
> Or take the case of a doctor looking at a patient's records. Looks at history of tests, interviews with the patient, goes back to
> history (or not) etc. All of these pieces of information about the patient need to be locked while the doctor is perusing them.
>
> Robert
>

I think you miss my point

You state that you don't want anyone updating data
why you are looking at it but the opportunity exists
for that data to be updated an instant prior to or post
you looking at the data, so how can an update
at the instant you are looking at the data effect
any decision you make.

Lets say you make a decision because
Attribute A has a value of X but as soon as
you release the record Attribute A is updated to Y

Why does it affect your decision?
How does this affect your decision?

I have had 30 years experience in VLDB design
in systems that run 24*7*52
The statefulness of data is the single biggest issue
that arises in systems development, the above
two questions are the ones that need answering most.

In the end I always put to the business that
you must accept that the state of data is
only an instance of the database at the time
you choose to peruse it.

Look at it like this, you have a customer who
is in arrears at end of business and so the system
generates a letter that night, you print it off and
mail it to the customer, but said customer
comes in the same morning and pays off the
arrears, he is still going to get a letter stating
that he owes you money but "of course" your
letter duly states that if you have made a payment
to please disregard the letter

Thats how you have to look at data
Its state can change at any time so your
business practices have to be designed
to cater for that even if it is just a simple
"pro-forma" on the bottom of a letter.

gF

Tue, Jun 6 2006 9:09 AMPermanent Link

"Robert"

"GregF" <footyfacts@yahoo.com> wrote in message
news:C7D6BF61-FC6E-48BB-8BF4-CDFA98FE1FED@news.elevatesoft.com...
>
>
> You state that you don't want anyone updating data
> why you are looking at it but the opportunity exists
> for that data to be updated an instant prior to or post
> you looking at the data, so how can an update
> at the instant you are looking at the data effect
> any decision you make.
>
> Lets say you make a decision because
> Attribute A has a value of X but as soon as
> you release the record Attribute A is updated to Y
>


Thanks for the detailed response. This is probably not the right forum for
this conversation, but let me try to explain:

Attribute A is not simply an atomic piece of data. It affects a number of
rules within the system (call them R1, R2.. Rnn). So I have looked at R1,
pondered, had a cup of coffee, now I look at R2 and meanwhile somebody has
changed attribute A, and if I were to look again at R1 I would see a
different result. so R2 now is inconsistent with R1. I might or might not
notice this. But the value of the information is degraded if I allow ANY
changes while I'm evaluating the whole set.

Not to mention the massive logic complications when the verification of the
validity of an update requires looking at a number of other records.

I'm not saying this is always the case. Just that I've seen enough
situations where there is a need to lock a set of records, whether or not
any one in particular is changing.

>
> In the end I always put to the business that
> you must accept that the state of data is
> only an instance of the database at the time
> you choose to peruse it.
>

And the business might accept it because they have no choice. But in some
cases it is completely counterintuitive. With paper records, when I take a
folder out of the cabinet and leave a marker indicating that I have it,
nobody can add or subtract from that folder while it is in my posession. If
somebody needs to do an update, they'll have to wait until I return it. The
WHOLE THING is unavailable, not just the specific document I happen to be
reading now. And if their update requires checking the state of the
information in the folder before making a decision, they will have ALL of my
changes, so the information for the whole folder will be in a consistent
state.

Robert


Tue, Jun 6 2006 12:17 PMPermanent Link

"Jerry Clancy"
The need to prevent multiple users from killing each other has existed from
the advent of the first multitasking systems. We had to deal with this over
40 years ago now (geez, I'm really getting old) in the development of
OS/360. Deadlock and resource management were the other considerations. You
prevent deadlock by asking for all the resources at once and back off if you
can't get them all. However, from an application point of view, when you ask
for them can vary. Example: A user wants to book a seat on a flight. Let's
say four databases are involved. You can lock all the relevant records at
the time the user checks the flight. The user, however, could be a slow
decision maker (Robert's cup of coffee) and in the meantime others are
prevented from accessing those records. Or, you could present the data to
the users (four seats left), not lock the records and await his or her
decision. When made, you recheck availability and either lock them then or
send the user a "Sorry, Slow Joe, but while you were having coffee others
took your seats" message. (Of course, evil airlines just take their money
and overbook.)

This locking also can be done at a higher order. Years ago we needed to
prevent our data entry people from editing the same legislative bills at the
same time. Instead of locking all the bills at once we implemented a
semaphore system (and database for [then] global visibility). The semaphore,
though having a physical manifestation, is actually a concept: it represents
something. In our case it represented a bill and a user. Before editing a
record in any database for a specific bill the user would check to see if
there was an active semaphore for that bill. If so a "backoff" algorithm was
executed (wait so long and retry, etc.). If not, a semaphore was created,
logically "locking" that bill, and later released when processing was
completed.

Later, systems implemented transactional checkpoints and rollback to recover
from points of failure occurring while records were locked, logically or
physically.

The Delphi Edit may lock a physical record in a specific database but it is
only one piece or low-level action taking place in a larger architectural
view regarding the logical relationship of records and databases to one
another. Different applications will approach this in different ways. What
is important is that the integrity of the data remains sound. You generally
should not allow one user to make changes to records on the basis of
information provided that has since been changed by someone else (I except
only the cases where it is done knowingly for business reasons and
reconcilliation mechanisms are provided).

FWIW.

Jerry

« Previous PagePage 2 of 2
Jump to Page:  1 2
Image