Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 14 of 14 total |
Lock record to prevent editing |
Sun, Jun 4 2006 10:48 PM | Permanent 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 PM | Permanent 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 AM | Permanent 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 PM | Permanent 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 Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, March 28, 2024 at 08:36 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |