C
ChUIMonster
Guest
I do very much like your "banishment" flag idea. But... The reason that I think adding a named tool specifically to manage disconnections is that people don't think. Carefully executed actions that follow a defined procedure are the exception out there -- not the rule. The overwhelming majority of people responsible for OpenEdge databases are not trained and experienced OE DBAs and they they are very often not particularly trained at administering the OS that OE is installed on either. They are even less trained with regards to the peculiarities of OpenEdge (this was one of David's key points). We can advocate for adding all of the helpful technical safeguards in the world and people will still do the wrong thing. They *will* take the path of least resistance. Every time. And Progress will be blamed. Every time. To improve the behavior you need to make it really easy to do the right thing more often and, preferably, by default. Having the "disconnect" options buried in "proshut" is not exactly intuitive. And the lack of helpful, supportive tools to get untrained people through this process is problematic. Proshut doesn't even warn you if you are wanting to disconnect user #2 and accidentally select option #2 (yes, I have been personally traumatized by this, it was a long time ago but the pain still burns). This next bit veers off into technical minutiae but I didn't think there were any states where merely *waiting* for a latch causes a crash. I was under the impression that the session had to actually be executing the code protected by a latch for a panic to be appropriate. That makes sense to me -- the stuff going on inside latch protected code involves data that is local to the process execution. There would not be any reasonable way to undo half done changes. For instance -- if the latched code is moving an item on a linked list there are at least two pointers that need to be updated. The process making the change knows what item it is moving and which entries are being changed. Nobody else knows that. If it has changed the pointer to the original item to now point to the next item the list no longer knows where the original item is. If you crash at that point the thing you are moving will be lost - nobody is pointing to it. The list is consistent but incomplete. Likewise you could move it first and then remove it, but if you crash in the middle of those actions you have a double entry. In this case you might think that a second list could be keeping track of everything just in case and that in the event of a failure the list could be scanned and rebuilt. But that has a cost and we'd probably complain about that too. (My example may, or may not be anything that OpenEdge actually does -- I'm trying to keep it very simple. But there are certainly data structures protected by latches for consistency reasons and the performance trade off has to be considered.)
Continue reading...
Continue reading...