[648] in Tooltime
Duplication/Locking problems
daemon@ATHENA.MIT.EDU (Debi Fuchs)
Fri Dec 5 15:30:14 1997
Date: Fri, 5 Dec 1997 15:30:20 -0500
To: tooltime@MIT.EDU
From: Debi Fuchs <debi@MIT.EDU>
Hello all,
I've been looking at the TCL code...forgive me. I have a suggestion of how
to make the log duplication problem happen less frequently, a suggestion as
to the cause of the problem, a way to duplicate the problem reliably, a
report of a new more serious bug, and a plea that we rethink the locking
mechanism if there is a chance that we will be using Scopus for more than a
few months.
Cheers,
-Debi
A suggestion about how to instantly make log duplication happen less
frequently:
----------------------------------------------------------------------
As David told me on the other day on the phone, the reason logs are being
duplicated under a new log number is that the form state, which indicates
whether the information on the screen represents a new log or an existing
one, seems to be sometimes incorrect. This is a problem.
If a log actually exists, but the form state incorrectly indicates that it
doesn't, it is treated as a new log, anyway, and thus a duplicate log is
generated under a new log number.
Fixing the underlying problem may be hard (see below). For now, however,
can we at least check that the log number field displayed on the screen is
empty before trusting the form_state flag that a given log is really a new
one?
The code to save a log contains the following:
if {$form_state == 0} {
[code to insert a new log here]
}
if {$form_state == 1} {
[code to update values on existing log here]
}
Can we change it to something like:
if {$form_state == 0} {
if there IS NOT log number displayed in the log number field
then [code to insert a new log here]
else [diplay some error message, etc.]
}
}
if {$form_state == 1} {
[code to update values on existing log here]
}
A suggestion as to the cause of the problem:
--------------------------------------------
In looking at the code, I think part of the problem or (ONE problem) is
that the form state is not set to "EXISTS" as it should be in some cases,
such as if a user selects from the "find log" result set a log which has
somehow previously been left locked by himself for WHATEVER reason (i.e.,
because it is still open on another machine, because a machine crashed and
the log was left locked, because the user caused some error to occur such
that clearing the log did not result in unlocking a locked record, etc.)
Here is the offendingcode under "proc mit_log_find_cb".
if the log is locked by another user {
[show warning, disable all buttons which would result in a save]
return
}
...
if {$lock_flag == "Y"} return
...
op_setstate_exist_tcl $frm
op_updatestate_tcl $frm
Note that the procedure exits if the log is locked, either by you or by
another user, before the code is executed to update the form state.
Luckily, in the case of another user, all buttons are at least disabled
which would result in a save...so theoretically, you can't duplicate other
people's logs. (Unfortunately, I found that you CAN unknowingly unlock and
overwrite their changes by using the "New" button...see below)
One can reliably reproduce the log duplication problem as follows:
1.) Have a log showing on the screen (i.e. you have it locked).
Remember the log number.
2.) Change the Log Number to something stupid
3.) Save the log and click away any error messages
4.) Click "Clear All" button to get rid of the log
(Note, the log from #1 is still marked as locked
by you.)
5.) Type the log number from step 1 into the log number field
and click "Find Log"
6.) Double-click on the resulting log in the found set.
7.) Save the log. Walla, you have two!!!!!
(You can tell you're about to duplicate a log if the Save button is
showing, but the Close button is not.)
A new, serious bug:
-------------------------------------------------------
Unfortunately, I believe the new code that was added to unlock the log
currently showing on the screen before the "New" button is pressed does
this irregardless of who holds the lock. Thus, if Jerry Burke is over in
E40 modifying a log, and if I look at it from here (after okaying the
message saying I can't modify it), and I click on "New" log, Jerry's log
becomes unlocked.
To duplicate this problem:
1.) Use "View Locks" and note down the a log number of a log locked by
someone else. (Warn them beforehand)
2.) Type the log number from step 1 into the log number field
and click "Find Log"
3.) Click away the dialog box.
4.) Click on the "New" button to create a new log.
5.) Look at "View Locks" again and you'll see that the log from #1 is no
longer locked.
(Be sure to tell the person to save their log again so they can relock it.)
Okay, here's my plea for a rewrite of some of the code:
-------------------------------------------------------
I think there is a lot of work to be done to fix the code for keeping track
of the state of the LOCK status for a given form.
If we just miss one action, or if a machine crashes, or if a user is on
more than one machine, or anything unexpected happens, things can get all
messed up. There are so many places where we have to set or query the LOCK
status of a log; it seems very easy for things not to work right.
I guess the underlying problem is that Scopus forces us to ask:
"What does the LOCK status of this log indicate" rather than
"Is this log currently showing on anyone's machine right now"
Maybe we can think about a different mechanism for dealing with locked
logs, or make locking logs more explicit on the part of the user. I dunno.
Let's think about it.
Cheers,
-Debi
-------------
Debi Fuchs, Consultant
MIT Information Systems
Computing Help Desk Group
77 Massachusetts Avenue, 11-319
Cambridge, MA 02139
(617) 253-7812
debi@mit.edu
