Changes between Version 2 and Version 3 of SchedTechManual/ServerChanges1_7

Timestamp:

Jul 10, 2012, 2:23:47 PM (12 years ago)

Author:

Sam Habiel

Comment:

--

SchedTechManual/ServerChanges1_7

@@ -6 +6 @@
 1. The interaction between transactions and locking causes a freeze in GT.M that looks like this:
 {{{
-GTM[******]: %%GTM-W-MUTEXLCKALERT, Mutual Exclusion subsystem ALERT - lock attempt threshold crossed for region /var/worldvista/globals/mumps.dat.  Process 17141 is in crit. -- generated from 0x00002B158FF975CD.
+GTM[******]: %%GTM-W-MUTEXLCKALERT, Mutual Exclusion subsystem ALERT - 
+lock attempt threshold crossed for region /var/worldvista/globals/mumps.dat.  
+Process 17141 is in crit. -- generated from 0x00002B158FF975CD.
 }}}
 The Scheduling GUI did a lock itself outside of the transaction in BSDX07, and Fileman did a bunch of locks internally inside the transaction.
@@ -15 +17 @@
 
 Due to all of these reasons, I decided to completely remove Mumps Transactions from the Scheduling GUI code.
+== Summary of Work ==
+6 routines had to be changed: BSDX07, BSDX08, BSDX25, BSDX26, BSDX29, BSDX31.
+The general approach is as follows: First, we check against PIMS if applicable if we can store the data in PIMS. If we can, we go ahead and 
+ 1. File the data in BSDX APPOINTMENT, and then 
+ 2. in PIMS, and then 
+ 3. run the Appointment Event driver (SDAM APPOINTMENT EVENTS in the Protocol File). This last step is the point of no return.
+If we fail in 1, we don't need to roll back anything. If we fail in 2, we need to rollback #1. If we fail in 3, we really don't have any recourse.
+For practical reasons, I decided that I will handle errors that can be reported to me (e.g. Fileman failing to store data). Mumps level errors I cannot handle gracefully; however, I put code to try to recover in certain places where I thought it would be practical to do so.
+