[245] in Tooltime
locking problem ideas
daemon@ATHENA.MIT.EDU (Steven Wade Neiterman)
Thu Sep 12 15:24:14 1996
Date: Thu, 12 Sep 1996 15:25:26 +0100
To: tooltime@MIT.EDU
From: wade@MIT.EDU (Steven Wade Neiterman)
Understanding that locking is a problem. Here is a senario that does not
use any "program" locks, e.g. changing values in a record to identify that
a record is locked.
This senario is typical of transaction based systems. There are questions
that need resolution to determine if this is possible.
It would be preferable to not "program" the lock since it is getting very
complex.
.....
1. The consultant selects a record using QBE or the "find open" seelct.
Let's say the person finds all Eudora records and the result set has 133
records.
2. The consultant starts "walking" through the result set, viewing records.
3. If the consultant wants to modify a record, he/she would first invoke
a button called "modify". This would reissue a select command with update.
For example "select columns from table where ... for update nowait".
The addition of the "for update nowait" will lock the record.
Let's say consultant A is viewing a record and two minutes later consultant
B selects the same record. If consultant B wants to make a change,
he/she would reselect the record with an update option via hitting the
"Modify" button. The "Modify" button would enable the Save button.
Consultant B makes the change, hits the save button, the commit takes
place and the record is unlocked.
If consultant A (still viewing the record), decides to make a change,
he/she would hit the "modify" button and the record would be once again
be selected from the database with the change from consultant B.
Question: Can Scopus deal with the update on the select statement?
Can Scopus reissue the select based on the original select
statement?
These questions apply anytime we get a new record from a result set.
4. If the consultant hit's "modify", then decides not to hit "save", but
wants to get another record in the 133 list of Eudora questions, we
would need to issue a commit somewhere (as part of the callback routine?)
to clear the lock. This is true regardless if the consultant started to
make changes or not, but just wanted to get another record after hitting
the modify button.
Question: Can we get Scopus to issue a commit on the act of selection?
5. If the consultant retrieves a record and starts to modify it without
hitting the "modify" button, then realizes that this button must be
used, he/she would lose any changes typed as the record is reselected
from the database. After doing this a few times, a consultant would
understand the process.
