RE: [U2] Inter-Process Control...
We are using Unix semaphores under Universe 10.0, with GCI C code that was ported from Pr1me by a third party. If you are interested in having a look at this I'll check with the powers-that-be. David Norman Senior Software Engineer - SA Ambulance Service ICT Services SA Health Government of South Australia Box 3, GPO Adelaide, South Australia 5001 *+61 8 8274 0384 * fax +61 8 8271 4844 * norman.da...@saambulance.com.au This e-mail may contain confidential information, which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail. If this e-mail is received in error, please inform the sender by return e-mail and delete the original. If there are doubts about the validity of this message, please contact the sender by telephone. It is the recipient's responsibility to check the e-mail and any attached files for viruses. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
hmmm. Are you running on a unix system? Maybe you could do this with a named pipe. have the waiting program open a named pipe for reading and wait and have the sending program open the named pipe for writing and send the message. George -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2- us...@listserver.u2ug.org] On Behalf Of Larry Hiscock Sent: Thursday, February 26, 2009 4:47 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... Yep ... sure miss sem$wait sem$notify. You could accomplish the same thing with a simple socket-based protocol. The main process could listen on a socket and wait for any of the sub-processes to connect and send a message via the socket. Larry Hiscock Western Computer Services -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Thursday, February 26, 2009 12:25 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... I agree. I wrote two little programs. LOCK.TEST1 0001 LOCK 60 ELSE CRT '60 LOCKED' 0002 CRT 'UNLOCKED' LOCK.TEST2 0001 UNLOCK 60 0002 CRT '60 WAS UNLOCKED' LOCK.TEST1 locked 60 displayed unlocked. LOCK.TEST2 generated the error ' Program LOCK.TEST2: Line 1, Lock 60 not owned by calling process' and then displayed 60 WAS UNLOCKED. As I was playing with the test programs as I type this. it looks like the first process needs to perform the first lock. The second process will then lock, and wait on the lock until the first process unlocks. I need to be able to support many-to-one processes. The one process waits on the lock and any of the many processes need to release the lock... which the old semaphore process supported... I confess, I'm spoiled. :) Thanks Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, February 26, 2009 2:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Tom, can you elaborate when you say the only process that can modify the lock is the one that set it. Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
Couldn't you get the second phantom to lock an empty record release it when it is done? The first phantom can wait on the readu lock. Regards, Kishor Parmar -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: 26 February 2009 12:57 To: u2-users@listserver.u2ug.org Subject: [U2] Inter-Process Control... We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on something, so it only wakes up when it needs to perform its function? To try to explain better: Phantom1: Loop Wait on semaphore Perform a shared process (batch updates would be an example) Repeat Phantom2 (3, 4, ...): Loop Process records Notify semaphore Repeat Thanks, Tom Whitmore RATEX Business Solutions --- 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/
Re: [U2] Inter-Process Control...
Tom, Sounds like a classic application for sockets. Inter process communications. Phantom 1 opens a server socket on a known port/IP and waits on a blocked read for something (like a process name to run for example). Process 2 opens a socket on the known port/ip and writes the name of the process it would like to have run and perhaps provides some parameters as either a command line or second write. Process 1 fires off the requested process and writes and response. Tom Whitmore wrote: We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on something, so it only wakes up when it needs to perform its function? To try to explain better: Phantom1: Loop Wait on semaphore Perform a shared process (batch updates would be an example) Repeat Phantom2 (3, 4, ...): Loop Process records Notify semaphore Repeat Thanks, Tom Whitmore RATEX Business Solutions --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com /Come To The Dark Side, We Have Cookies./ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Inter-Process Control...
We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on something, so it only wakes up when it needs to perform its function? If you use the LOCK command (e.g.: LOCK 17) you're using semaphores. Does that suit your needs? If you're on UniData, you may want to take a look at PAUSE and WAKE. It gives you a way for a process to go to sleep, allowing another process to wake it up. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
If this is the approach you go for, I would recommend that you use a resource lock, rather than a record lock (no need to open file etc etc)... Resource locks are set system wide, so are not limited to a single account / file / record, and are accessed with the LOCK/UNLOCK UniBasic commands... You have 64 locks to use as you see fit.. In my mind the solution depends on how quickly you need the second process to wake up.. if a 30sec+ delay is ok, then using a resource lock could be an option with a SLEEP 30 on the locked condition.. Otherwise I would be looking at launching the child job as required, rather than having it wait for work.. Regards Raymond de Bourbon From: owner-u2-us...@listserver.u2ug.org [owner-u2-us...@listserver.u2ug.org] On Behalf Of kishor [kis...@parmars.com] Sent: 26 February 2009 07:52 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... Couldn't you get the second phantom to lock an empty record release it when it is done? The first phantom can wait on the readu lock. Regards, Kishor Parmar -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: 26 February 2009 12:57 To: u2-users@listserver.u2ug.org Subject: [U2] Inter-Process Control... We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on something, so it only wakes up when it needs to perform its function? To try to explain better: Phantom1: Loop Wait on semaphore Perform a shared process (batch updates would be an example) Repeat Phantom2 (3, 4, ...): Loop Process records Notify semaphore Repeat Thanks, Tom Whitmore RATEX Business Solutions --- 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/
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. Also, I could not get the process to wait on the lock. 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/
Re: [U2] Inter-Process Control...
Tom, can you elaborate when you say the only process that can modify the lock is the one that set it. Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
I agree. I wrote two little programs. LOCK.TEST1 0001 LOCK 60 ELSE CRT '60 LOCKED' 0002 CRT 'UNLOCKED' LOCK.TEST2 0001 UNLOCK 60 0002 CRT '60 WAS UNLOCKED' LOCK.TEST1 locked 60 displayed unlocked. LOCK.TEST2 generated the error ' Program LOCK.TEST2: Line 1, Lock 60 not owned by calling process' and then displayed 60 WAS UNLOCKED. As I was playing with the test programs as I type this. it looks like the first process needs to perform the first lock. The second process will then lock, and wait on the lock until the first process unlocks. I need to be able to support many-to-one processes. The one process waits on the lock and any of the many processes need to release the lock... which the old semaphore process supported... I confess, I'm spoiled. :) Thanks Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, February 26, 2009 2:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Tom, can you elaborate when you say the only process that can modify the lock is the one that set it. Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- 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/
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 ;* 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 ;* 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/
RE: [U2] Inter-Process Control...
Yep ... sure miss sem$wait sem$notify. You could accomplish the same thing with a simple socket-based protocol. The main process could listen on a socket and wait for any of the sub-processes to connect and send a message via the socket. Larry Hiscock Western Computer Services -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Thursday, February 26, 2009 12:25 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... I agree. I wrote two little programs. LOCK.TEST1 0001 LOCK 60 ELSE CRT '60 LOCKED' 0002 CRT 'UNLOCKED' LOCK.TEST2 0001 UNLOCK 60 0002 CRT '60 WAS UNLOCKED' LOCK.TEST1 locked 60 displayed unlocked. LOCK.TEST2 generated the error ' Program LOCK.TEST2: Line 1, Lock 60 not owned by calling process' and then displayed 60 WAS UNLOCKED. As I was playing with the test programs as I type this. it looks like the first process needs to perform the first lock. The second process will then lock, and wait on the lock until the first process unlocks. I need to be able to support many-to-one processes. The one process waits on the lock and any of the many processes need to release the lock... which the old semaphore process supported... I confess, I'm spoiled. :) Thanks Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, February 26, 2009 2:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Tom, can you elaborate when you say the only process that can modify the lock is the one that set it. Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- 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/
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 ;* 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 ;* 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/
RE: [U2] Inter-Process Control...
A point to remember if using sockets (on UniVerse) is that your phantom will become an iphantom, and thus consume a license. Regards Bernard Lubin -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Larry Hiscock Sent: Friday, 27 February 2009 8:47 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... Yep ... sure miss sem$wait sem$notify. You could accomplish the same thing with a simple socket-based protocol. The main process could listen on a socket and wait for any of the sub-processes to connect and send a message via the socket. Larry Hiscock Western Computer Services -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Thursday, February 26, 2009 12:25 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... I agree. I wrote two little programs. LOCK.TEST1 0001 LOCK 60 ELSE CRT '60 LOCKED' 0002 CRT 'UNLOCKED' LOCK.TEST2 0001 UNLOCK 60 0002 CRT '60 WAS UNLOCKED' LOCK.TEST1 locked 60 displayed unlocked. LOCK.TEST2 generated the error ' Program LOCK.TEST2: Line 1, Lock 60 not owned by calling process' and then displayed 60 WAS UNLOCKED. As I was playing with the test programs as I type this. it looks like the first process needs to perform the first lock. The second process will then lock, and wait on the lock until the first process unlocks. I need to be able to support many-to-one processes. The one process waits on the lock and any of the many processes need to release the lock... which the old semaphore process supported... I confess, I'm spoiled. :) Thanks Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, February 26, 2009 2:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Tom, can you elaborate when you say the only process that can modify the lock is the one that set it. Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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 ;* 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 ;* 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/
RE: [U2] Inter-Process Control... {Unclassified}
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 ;* 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 ;* 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
