Changes between Version 2 and Version 3 of SchedTechManual/ServerChanges1_7

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



  • SchedTechManual/ServerChanges1_7

    v2 v3  
    661. The interaction between transactions and locking causes a freeze in GT.M that looks like this:
    8 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.
     8GTM[******]: %%GTM-W-MUTEXLCKALERT, Mutual Exclusion subsystem ALERT -
     9lock attempt threshold crossed for region /var/worldvista/globals/mumps.dat. 
     10Process 17141 is in crit. -- generated from 0x00002B158FF975CD.
    1012The Scheduling GUI did a lock itself outside of the transaction in BSDX07, and Fileman did a bunch of locks internally inside the transaction.
    1618Due to all of these reasons, I decided to completely remove Mumps Transactions from the Scheduling GUI code.
     19== Summary of Work ==
     206 routines had to be changed: BSDX07, BSDX08, BSDX25, BSDX26, BSDX29, BSDX31.
     21The 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
     22 1. File the data in BSDX APPOINTMENT, and then
     23 2. in PIMS, and then
     24 3. run the Appointment Event driver (SDAM APPOINTMENT EVENTS in the Protocol File). This last step is the point of no return.
     25If 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.
     26For 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.