I do understand the concern, and the concept of "optimistic locking". Our application will have session timeout logic, so we can clean-up any locks. We will be developing tools to keep the control records cleaned up. Our problem is that we cannot use optimistic locking for the application.
Tom -----Original Message----- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR Sent: Thursday, February 26, 2009 6:06 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... {Unclassified} Tom, I don't think that 'maintaining a lock manager' is necessarily a good solution to non-persistent connections. A more conventional approach is for each connection to maintain the state of the record(s) it was going to modify - i.e. a 'before image'. Then, when it's time to apply the transaction, you lock the records (READU), and check that the records now on disk are in the same state as their before images. If they are, you can safely overwrite them. If they are not all the same as before, you unlock them and tell the user that someone else has changed the data and bad luck, please start again. This is known as the "optimistic locking" design philosophy. You also need a Phantom process to go through and clean out all the old 'before image' data that users never came back to. Of course, if you get too many oops-somebody-else-changed-it collisions, you may need to use persistent connections or a re-architecting of the data and/or application to reduce the frequency of collisions. Hope this helps Mike -----Original Message----- From: owner-u2-us...@listserver.u2ug.org On Behalf Of Tom Whitmore Sent: Friday, 27 February 2009 11:21 a.m. To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... One example of what I'm trying to do is develop a record lock manager (for the lack of a better description) for non-persistent connections. I need the lock manager to wakeup when there is a request for a readu/write/delete. The all the "responders" would need to send requests to the "lock manager". We have other processes that could use this functionality as well. I hope that helps, Tom -----Original Message----- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of iggch...@comcast.net Sent: Thursday, February 26, 2009 4:09 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Hey Tom, Are you trying to do something like... Program A B B B B DONE = 0 B B B B LOOP B B B B B B B B B B GOSUB XXXX;* PROCESS STUFF B B B B B UNTIL DONE DO B B B B B B B B B B B IF SOME.EVENT THEN B B B B B B B B B B B B B B B B LOCK 10;* WAKE UP PROGRAM B B B B B B B B B B B B B END B B B B B B B B B B B LOCK 11 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B END ELSE B B B B B B B B B B B B B B B B B B UNLOCK 10;* PROGRAM B FINISHED B B B B B B B B B B B END B B B B B B B B B B B B SLEEP 30 B B B B B B REPEAT B B B B B B B STOP PROGRAM B B B B B B B B DONE = 0 B B B B B B LOOP B B B B B B B B B B B B B LOCK 10 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 10 B B B B B B B B B B B B B B ENDB ELSE B B B B B B B B B B B B B B B B B B B B LOCK 11 B B B B B B B B B B B B B B B B B B B B GOSUB XXXX;* PROCESS STUFF B B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B B B END B B B B B B B UNTIL DONE DO B B B B B B B B B B B B B B SLEEP 30 B B B B B B B REPEAT B B B B B B B B STOP ----- Original Message ----- From: "Tom Whitmore" <tewhitm...@ratex.com> To: u2-users@listserver.u2ug.org Sent: Thursday, February 26, 2009 12:05:19 PM GMT -06:00 US/Canada Central Subject: RE: [U2] Inter-Process Control... Thank you for all the responses. I should have stated that we are a UniVerse shop. I did play with the lock/unlock but the only process that can modify the lock is the one that set it. B Also, I could not get the process to wait on the lock. B From the playing I did, lock/unlock seems very limited compared to what was available 15 years ago. Thanks Tom ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/