Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
You are right, you don't always know in advance which records you need to lock. If the processes are human controlled this can be solved by letting each user know who is locking whom out and they can solve the problem hopefully themselves. If phantom processes are doing this you don't have this option and you may have to employ the error log option or in case of a single file the loop with the sleep or even a combination of the two. If it is really hairy you may have to use transactions and don't commit until all records have been written. If a locking issue hasn't been resolved within such and such a time just release all locks and start again. So far I never had to do that, but AFAIK UniBasic has that feature and if you have so much trouble with phantoms locking each other out you should probably look at that option too. Or maybe ask yourself if you really need that many phantoms? There is no standard solution for every case but with a bit of thought every deadlock situation can be avoided or solved. In my experience locking problems are caused to 99% by users sitting in maintenance screens while they are doing something else like playing with spread sheets, sitting in meetings or go home without logging off. User A gets a message that he can't proceed because user B holds a lock. If he tries to ring user B and can't reach him he rings IT and I kick user B out ;-). Simple as that! Happens about once a week. I can live with that, but if it would be happening more frequently or with phantoms I would do something about it. In any case if you use READU use the locked clause because only then you have the option to bail out and avoid a deadlock. On 26/10/2011 01:36, Wjhonson wrote: It is not possible to know in advance all the locks you may wish to set. That's the problem. -Original Message- From: Charles Stevensonstevenson.c...@gmail.com To: U2 Users Listu2-users@listserver.u2ug.org Sent: Tue, Oct 25, 2011 5:22 pm Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu. While Will's articledoes give a good, clear example of a deadly embrace, nd remediating faulty code is not trivial, the solution is conceptually rivial and it is exactly the LOCKED clause that saves us. If you write new code, deadlocks are easy to prevent. Testing is non-trivial. It generally requires load or stress testing here mutiple processes vie for the same locks. In a nutshell: you shouldn't begin writing ANY part of a logical ransaction until you own ALL necessary locks. LOCKED clauses help you rap cases where you can't get one of those needed locks, allowing you o release all other related locks, (freeing up everything so the ompeting process can finish its work), then you try again. No eadlocks. QED. My problem posed at the start of this thread represents a conceptually rivial project but it will include retrofitting this anti-deadlock ogic. Non-trivial hours. Opportunity costs. More consistent data! All MV platforms support this same solution. If someone else wants to explain it in further detail for the newbies, lease, be my guest. cds On 10/25/2011 12:27 PM, Wjhonson wrote: This is deadly embrace http://knol.google.com/k/will-johnson/deadly-embrace-on-pick-systems/4hmquk6fx4gu/816#view The Locked clause does not save us from it. There is no known trivial olution to the problem, which troubles all multi-table, multi-user database nvironments. Perhaps we should start a new thread to discuss various approaches to the ssue. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Avoiding deadly embraces (was Re: [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.)
Hi, You can avoid a deadly embrace if you can arrange it so that all processes lock related tables/files in the same sequence. Take the example of a system with a CUSTOMER file, a ORDER HEADER file and an ORDER DETAILS file. If some processes lock the ORDER HEADER file first and the CUSTOMER file second, and other processes do it the other way around, then you will end up, sooner or later, with a deadly embrace, If all processes always lock the ORDER HEADER file first and the CUSTOMER file second, then you wont get a deadly embrace. You will get the situation where there is contention for the same CUSTOMER record, but it wont be a deadly embrace. One process will be holding the lock, and the other one will need to wait. In the normal course of events the process holding the CUSTOMER lock will finish and relinquish the lock, and allow the waiting process to acquire the lock and continue. cheers, asvin From: Wjhonson wjhon...@aol.com To: u2-users@listserver.u2ug.org Date: 25/10/2011 18:28 Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu. Sent by: u2-users-boun...@listserver.u2ug.org This is deadly embrace http://knol.google.com/k/will-johnson/deadly-embrace-on-pick-systems/4hmquk6fx4gu/816#view The Locked clause does not save us from it. There is no known trivial solution to the problem, which troubles all multi-table, multi-user database environments. Perhaps we should start a new thread to discuss various approaches to the issue. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised and regulated by the Financial Services Authority. - SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group HSBC for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
Accountants... How about a ER doc waiting on lab results for cardiac enzymes? I can hear it now: Sorry Doc, something else locked the record. Your patient's test request was skipped so we could implement a trivial solution that was suggested for deadly embrace. Try again, and hope for the best that it goes through this time. Robert F. Porter, MCSE, CCNA, ZCE, OCP-Java Lead Sr. Programmer / Analyst Laboratory Information Services Ochsner Health System This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Wjhonson wjhon...@aol.com 10/25/2011 1:20 PM Your second solution only works if one of the processes is controlled by a human. I've encountered deadly embraces between two phantom routines. Your first solution works, if we have the luxury of skipping locked records. Some update routines, don't have that luxury as most accountants will let you know quite clearly with loud noises and waving of arms. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
On 26/10/11 00:23, Steve Romanow wrote: I reread my post and meant no disrespect Wols. I shouldnt post replies without considering twice. No worries Steve. I shoot from the hip sometimes too - it can be embarrassing :-) Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Avoiding deadly embraces
I find the best practice is to try and lock and read all the necessary components before the first update. That way if an item we need to update as we go along is unavailable we catch it up front and don't get stuck. Or if you have TRANSACTION PROCESSING in place you can just to an ABORT. I would also never just READU but do the RECORDLOCK or the READU with the LOCKED clause to be able to control program flow. You can send messages to those users that have the locked items even a text message or email. If you are in a nightly batch process then do as another suggested and keep a list of IDs and try to process them again at the end. Send an exception report via email to the ones in charge. Set inactivity timeouts on record updates that require user intervention. It would be awfully sad if Shipping can't ship because a Customer Service Rep was going to update the customers email and then got called away. Something else that helps, keep the transactional data in a separate file than the master record. For instance the Last_Shipped data shouldn't be in the same record as the Customer's Address and email. This way the customer screen can show the data in a view only mode with no need to lock the record that the shipping department will need to update to do its job. David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Avoiding deadly embraces
It's not possible to know every lock you may wish to set in advance David, that's the problem. Some locks can be set, but unknown, until the user has done something. Like in my example where the user changing a field in one record, causes another update to be triggered in some other record. You cannot know that in advance, that is, you cannot determine what the user may do next, so you cannot set the lock in advance, but only at-the-time they act, which will be after the main lock is set on Record A. To Asvin, you cannot set locks in the same sequence every time. This is because, in a sufficiently complex system you will have changes to Customer's possibly affecting Orders, Inventory, Payables... You can then have changes to Inventory possibly affecting Orders, Customers, Receivables... You can then have changes to Receivables, affecting Orders, Customers, Inventory... You can then have changes to Sales Reps affecting Customers, Orders, Payroll... The route from A to E is not the same as the route from B to G and then back to C. So that's another problem. It seems like some of you have only ever worked on rather simple systems, built by yourselves :) Try working on systems that have been accreting for twenty years, and built by sixteen other programmers over that time period. There is no simple deterministic way to avoid deadly embraces through code alone. -Original Message- From: David A. Green dgr...@dagconsulting.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Wed, Oct 26, 2011 6:42 am Subject: Re: [U2] Avoiding deadly embraces I find the best practice is to try and lock and read all the necessary omponents before the first update. That way if an item we need to update s we go along is unavailable we catch it up front and don't get stuck. r if you have TRANSACTION PROCESSING in place you can just to an ABORT. I would also never just READU but do the RECORDLOCK or the READU with the OCKED clause to be able to control program flow. You can send messages to hose users that have the locked items even a text message or email. If you re in a nightly batch process then do as another suggested and keep a list f IDs and try to process them again at the end. Send an exception report ia email to the ones in charge. Set inactivity timeouts on record updates that require user intervention. t would be awfully sad if Shipping can't ship because a Customer Service ep was going to update the customers email and then got called away. Something else that helps, keep the transactional data in a separate file han the master record. For instance the Last_Shipped data shouldn't be in he same record as the Customer's Address and email. This way the customer creen can show the data in a view only mode with no need to lock the ecord that the shipping department will need to update to do its job. David A. Green 480) 813-1725 AG Consulting __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
Come on, get real. Do you suggest the deadly embrace would be better and he would get his results any quicker? And anyway, an ER doc not getting his lab results because of a mass update process running as a phantom encountering a locked record? And who would hold a lock on those lab results while they are being transferred? Come up with a real life problem and I'll give you a real life solution. Remember, the impossible I do straight away but miracles may take a bit longer! Mecki On 26/10/2011 13:45, Robert Porter wrote: Accountants... How about a ER doc waiting on lab results for cardiac enzymes? I can hear it now: Sorry Doc, something else locked the record. Your patient's test request was skipped so we could implement a trivial solution that was suggested for deadly embrace. Try again, and hope for the best that it goes through this time. Robert F. Porter, MCSE, CCNA, ZCE, OCP-Java Lead Sr. Programmer / Analyst Laboratory Information Services Ochsner Health System This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Wjhonsonwjhon...@aol.com 10/25/2011 1:20 PM Your second solution only works if one of the processes is controlled by a human. I've encountered deadly embraces between two phantom routines. Your first solution works, if we have the luxury of skipping locked records. Some update routines, don't have that luxury as most accountants will let you know quite clearly with loud noises and waving of arms. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
I'm suggesting that blinding skipping records is a HORRIBLE idea, and in our case, potentially life threatening - literally. You need to get real with your suggestion that coding for deadly embrace situations is a very easy solution (your words). Not every phantom is a mass update. The IS real-life... we're talking about 1/2 dozen hospitals plus around 4 dozen clinics all putting orders in and receiving status updates results in real time 24x7, the possibility for such occurrences takes REAL programming responses not off the cuff and rather simplistic canned answers. In fact, record locks for patient's lab results occurs all the time. We've taken many steps to minimize the possibility of a deadly embrace occurring - such as wrapping READU calls within a single subroutine that allows us significant;y better monitoring and control and programming practices. Some processes that lock have users in front of them -MLTs, MTs, MDs PhDs putting in results and interpretations . Some don't - interfaces in- and out-bound to dozens of systems for example. Sorry, but as I've been working with lab results for over 15 years now, I know what I'm talking about. It doesn't get any more real... sorry to burst your bubble. So you come on ... admit that programming for this is not a very easy solution. Robert Mecki Foerthmann mec...@gmx.net 10/26/2011 2:44 PM Come on, get real. Do you suggest the deadly embrace would be better and he would get his results any quicker? And anyway, an ER doc not getting his lab results because of a mass update process running as a phantom encountering a locked record? And who would hold a lock on those lab results while they are being transferred? Come up with a real life problem and I'll give you a real life solution. Remember, the impossible I do straight away but miracles may take a bit longer! Mecki On 26/10/2011 13:45, Robert Porter wrote: Accountants... How about a ER doc waiting on lab results for cardiac enzymes? I can hear it now: Sorry Doc, something else locked the record. Your patient's test request was skipped so we could implement a trivial solution that was suggested for deadly embrace. Try again, and hope for the best that it goes through this time. Robert F. Porter, MCSE, CCNA, ZCE, OCP-Java Lead Sr. Programmer / Analyst Laboratory Information Services Ochsner Health System This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Wjhonsonwjhon...@aol.com 10/25/2011 1:20 PM Your second solution only works if one of the processes is controlled by a human. I've encountered deadly embraces between two phantom routines. Your first solution works, if we have the luxury of skipping locked records. Some update routines, don't have that luxury as most accountants will let you know quite clearly with loud noises and waving of arms. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Avoiding deadly embraces
What do you think I am doing day in day out? I work with Avante 9.2 from Epicor and I definitely didn't write that myself. And this isn't the first system I've worked with in nearly 25 years in the MV world. And to be honest I have barely scratched the surface of Avante since I only look at the code if it requires modification or there is a problem. I don't know how many programmers were involved in writing it but I guess it was a lot more than 16. Some of it looks like it's very old since it uses soft locks and it contains some really weird and whacky code. And yes, we have occasional locking issues but never deadly embraces because the software is written in a way that helps to prevent or solve them. The software generally uses standard subroutines to read and lock records and notifies the user if somebody else holds a lock and who that user is. It could of course be better and display the user name instead of the login ID but most people can figure out whom to ring if they are locked out. Some programs display only the port so they have to ring IT to find out who the user is - but with UniAdmin that is no big deal. Depending what the process does it gives the user the opportunity to try again or abort the process or displays the message until the lock is released should the process be in the middle of a multi file update. Other processes can only to be run by one user at a time and prevent anybody else from starting the process. About once a week I get a call because a lock stops somebody from doing their job and I have to kick the offending party off the system. If they loose their work - tough luck - everybody has been told not to leave a screen in the middle of something and walk away. I haven't had a complaint yet even when I kicked the MD off. Releasing the lock is hardly ever the right solution. That's why we have an IT department and what we get paid for - keeping the system running. Should I ever encounter problems like the ones you describe I would solve them and not whine about it! And should I struggle to find a solution I would ask the group for advice, take it, try it out and be thankful for it. Can't be done doesn't exist in my vocabulary. We have shown you a couple of solutions, but of course it is a lot easier to insist on the myth of deadly embraces, blame the stupid database system and insult your peers. Mecki On 26/10/2011 19:52, Wjhonson wrote: It seems like some of you have only ever worked on rather simple systems, built by yourselves :) Try working on systems that have been accreting for twenty years, and built by sixteen other programmers over that time period. There is no simple deterministic way to avoid deadly embraces through code alone. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Avoiding deadly embraces
Will - you couldn't be more wrong in your last paragraph. FWIW Knowing Asvin and the systems he works on I can tell you they are anything but simple - highly complex rules handling many hundreds of concurrent processes and millions of transactions per day... in fact right at the other end of the scale. Brian Sent from my ASUS Eee Pad Wjhonson wjhon...@aol.com wrote: It's not possible to know every lock you may wish to set in advance David, that's the problem. Some locks can be set, but unknown, until the user has done something. Like in my example where the user changing a field in one record, causes another update to be triggered in some other record. You cannot know that in advance, that is, you cannot determine what the user may do next, so you cannot set the lock in advance, but only at-the-time they act, which will be after the main lock is set on Record A. To Asvin, you cannot set locks in the same sequence every time. This is because, in a sufficiently complex system you will have changes to Customer's possibly affecting Orders, Inventory, Payables... You can then have changes to Inventory possibly affecting Orders, Customers, Receivables... You can then have changes to Receivables, affecting Orders, Customers, Inventory... You can then have changes to Sales Reps affecting Customers, Orders, Payroll... The route from A to E is not the same as the route from B to G and then back to C. So that's another problem. It seems like some of you have only ever worked on rather simple systems, built by yourselves :) Try working on systems that have been accreting for twenty years, and built by sixteen other programmers over that time period. There is no simple deterministic way to avoid deadly embraces through code alone. -Original Message- From: David A. Green dgr...@dagconsulting.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Wed, Oct 26, 2011 6:42 am Subject: Re: [U2] Avoiding deadly embraces I find the best practice is to try and lock and read all the necessary omponents before the first update. That way if an item we need to update s we go along is unavailable we catch it up front and don't get stuck. r if you have TRANSACTION PROCESSING in place you can just to an ABORT. I would also never just READU but do the RECORDLOCK or the READU with the OCKED clause to be able to control program flow. You can send messages to hose users that have the locked items even a text message or email. If you re in a nightly batch process then do as another suggested and keep a list f IDs and try to process them again at the end. Send an exception report ia email to the ones in charge. Set inactivity timeouts on record updates that require user intervention. t would be awfully sad if Shipping can't ship because a Customer Service ep was going to update the customers email and then got called away. Something else that helps, keep the transactional data in a separate file han the master record. For instance the Last_Shipped data shouldn't be in he same record as the Customer's Address and email. This way the customer creen can show the data in a view only mode with no need to lock the ecord that the shipping department will need to update to do its job. David A. Green 480) 813-1725 AG Consulting __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
I never said anything about blindly (I guess that's what you meant) skipping records. I suggested writing the locked record ids somewhere else and process them later for Wills not necessarily life-threatening sales rep update phantom. I at least don't feel threatened by accountants. If somebody is locking the record there must be a reason for it. If it's a good one or not doesn't matter. And who knows, when the process tries again a couple of minutes later the lock may have been released by then. That way a lock on a standard blood test doesn't stop the process from sending the important lab report next in line for processing to the ER doc you talked about. If it is really life threatening I would find out who holds the lock and take severe action instead. This could be an email or even a message sent directly to the locking screen that they are killing somebody in the hospital if they don't get out of Dodge immediately. And if they don't respond within a minute or so just kick them off the system. That will release the lock every time. You may also think about using optimistic locking for some or all of the processes that have users in front of them. You can even put some extra intelligence into that. So instead of refusing the update of a record because it has changed since it was read you can allow the update of empty attributes. All this can be done with 2 subroutines. One for reads and one for writes. It requires to write some code of course. But isn't that what we do for a living? Now I have never worked with lab results and came up with several solutions within minutes. Should be very easy to write for a 15 year veteran. And it sounds like you've done something similar, so what was so incredible hard about it? But maybe what I regard as easy may appear hard to others. Mecki On 26/10/2011 21:44, Robert Porter wrote: I'm suggesting that blinding skipping records is a HORRIBLE idea, and in our case, potentially life threatening - literally. You need to get real with your suggestion that coding for deadly embrace situations is a very easy solution (your words). Not every phantom is a mass update. The IS real-life... we're talking about 1/2 dozen hospitals plus around 4 dozen clinics all putting orders in and receiving status updates results in real time 24x7, the possibility for such occurrences takes REAL programming responses not off the cuff and rather simplistic canned answers. In fact, record locks for patient's lab results occurs all the time. We've taken many steps to minimize the possibility of a deadly embrace occurring - such as wrapping READU calls within a single subroutine that allows us significant;y better monitoring and control and programming practices. Some processes that lock have users in front of them -MLTs, MTs, MDs PhDs putting in results and interpretations . Some don't - interfaces in- and out-bound to dozens of systems for example. Sorry, but as I've been working with lab results for over 15 years now, I know what I'm talking about. It doesn't get any more real... sorry to burst your bubble. So you come on ... admit that programming for this is not a very easy solution. Robert Mecki Foerthmannmec...@gmx.net 10/26/2011 2:44 PM Come on, get real. Do you suggest the deadly embrace would be better and he would get his results any quicker? And anyway, an ER doc not getting his lab results because of a mass update process running as a phantom encountering a locked record? And who would hold a lock on those lab results while they are being transferred? Come up with a real life problem and I'll give you a real life solution. Remember, the impossible I do straight away but miracles may take a bit longer! Mecki On 26/10/2011 13:45, Robert Porter wrote: Accountants... How about a ER doc waiting on lab results for cardiac enzymes? I can hear it now: Sorry Doc, something else locked the record. Your patient's test request was skipped so we could implement a trivial solution that was suggested for deadly embrace. Try again, and hope for the best that it goes through this time. Robert F. Porter, MCSE, CCNA, ZCE, OCP-Java Lead Sr. Programmer / Analyst Laboratory Information Services Ochsner Health System This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Wjhonsonwjhon...@aol.com 10/25/2011 1:20 PM Your second solution only works if one of the processes is controlled by a human. I've
Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o explicit readu.
On 10/26/2011 7:45 AM, Robert Porter wrote: Accountants... How about a ER doc waiting on lab results for cardiac enzymes? I can hear it now: Sorry Doc, something else locked the record. Your patient's test request was skipped so we could implement a trivial solution that was suggested for deadly embrace. Try again, and hope for the best that it goes through this time. As opposed to what alternative? Remember, the ER doc is in this situation because some process wanting to deliver the lab results that the doc is waiting for is being blocked by locks held by a 2nd process. And, if it's a deadlock, that 2nd process can't proceed because the 1st has something it needs. So how should we respond to that scenario? Should we let the deadlock daemon handle it? It will kill one of the 2 processes. Perhaps the one the doc needs. Perhaps with data loss. Perhaps with data inconsistencies which might be even worse for said doc. Missing data is a Known Unknown. Lying data is an Unknown Unknown. Should we wait for IT staff to figure it out kill the process? I hope they kill the right one. Someone may be able to resubmit the transaction manually. Or maybe IT can cobble the data. That doesn't seem very timely if I'm the cardiac patient. - When I say trivial, I don't mean magic or even easy. The trivial part is the initial analysis: If you have deadlocks, then you need to add appropriate LOCKED clauses. There's a whole lotta non-trivial hours inside that word appropriate! The goal is to use a LOCKED clause to prevent entering a deadlock, then back off long enough so the other guy can complete his task, then you proceed. Most of the time, if you do it right, the whole thing will happen before the ER doc blinks. Actually, that's a general approach to lock blockage beyond deadlocks. For example, rather than camping on the readu, waiting for a lock for Result1, it can go ahead process Result2, allowing the ER doc to decide treatment for patient-2. BTW, the case of the potential deadlock is really the nicest of all possible lock problems because the process being blocked is in control of unblocking the process blocking him! Other situations are usually out of the program's control, such as a user on a coffee break, or file maintenance running late. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Avoiding deadly embraces
That's not really relevant to what I said. It's not a question at all of the *number* of transactions or processes, nor how complex the business rules are. It's much more relevant to the complexity of the history of the software. That someone would suggest that locks can be set in the same sequence in every case, illustrates the communication divide. -Original Message- From: Brian Leach br...@brianleach.co.uk To: U2 Users List u2-users@listserver.u2ug.org Sent: Wed, Oct 26, 2011 2:47 pm Subject: Re: [U2] Avoiding deadly embraces Will - you couldn't be more wrong in your last paragraph. FWIW Knowing Asvin and he systems he works on I can tell you they are anything but simple - highly omplex rules handling many hundreds of concurrent processes and millions of ransactions per day... in fact right at the other end of the scale. Brian Sent from my ASUS Eee Pad Wjhonson wjhon...@aol.com wrote: It's not possible to know every lock you may wish to set in advance David, hat's the problem. Some locks can be set, but unknown, until the user has done something. Like in my example where the user changing a field in one record, causes nother update to be triggered in some other record. You cannot know that in advance, that is, you cannot determine what the user ay do next, so you cannot set the lock in advance, but only at-the-time they ct, which will be after the main lock is set on Record A. To Asvin, you cannot set locks in the same sequence every time. This is because, in a sufficiently complex system you will have changes to ustomer's possibly affecting Orders, Inventory, Payables... You can then have changes to Inventory possibly affecting Orders, Customers, eceivables... You can then have changes to Receivables, affecting Orders, Customers, nventory... You can then have changes to Sales Reps affecting Customers, Orders, Payroll... The route from A to E is not the same as the route from B to G and then back to . So that's another problem. It seems like some of you have only ever worked on rather simple systems, built y yourselves :) Try working on systems that have been accreting for twenty years, and built by ixteen other programmers over that time period. There is no simple deterministic way to avoid deadly embraces through code lone. -Original Message- From: David A. Green dgr...@dagconsulting.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Wed, Oct 26, 2011 6:42 am Subject: Re: [U2] Avoiding deadly embraces I find the best practice is to try and lock and read all the necessary omponents before the first update. That way if an item we need to update s we go along is unavailable we catch it up front and don't get stuck. r if you have TRANSACTION PROCESSING in place you can just to an ABORT. I would also never just READU but do the RECORDLOCK or the READU with the OCKED clause to be able to control program flow. You can send messages to hose users that have the locked items even a text message or email. If you re in a nightly batch process then do as another suggested and keep a list f IDs and try to process them again at the end. Send an exception report ia email to the ones in charge. Set inactivity timeouts on record updates that require user intervention. t would be awfully sad if Shipping can't ship because a Customer Service ep was going to update the customers email and then got called away. Something else that helps, keep the transactional data in a separate file han the master record. For instance the Last_Shipped data shouldn't be in he same record as the Customer's Address and email. This way the customer creen can show the data in a view only mode with no need to lock the ecord that the shipping department will need to update to do its job. David A. Green 480) 813-1725 AG Consulting __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UniBasic Question
Oh, and Roadrunner is faster than Sonic ... definitely. :-) Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Tuesday, October 25, 2011 4:59 PM To: U2 Users List Subject: Re: [U2] UniBasic Question Unless you know the keys to the records you're selecting, even the EXECUTE SELECT ... is going to have to read each record, how else would it know which records to throw out? My point is, if one of your selection criteria were in the key, then my method bypasses the need to read the record if the key element fails its test. I concede the sort, however some relatively simple 'table' management can easily remedy that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of charles_shaf...@ntn-bower.com Sent: Tuesday, October 25, 2011 4:53 PM To: U2 Users List Subject: Re: [U2] UniBasic Question Dave The next-to-last one may depend on Unidata vs. Universe. I understand that Unidata only 'fetches' the key in the READNEXT while I believe Universe grabs both the key and record, due to the construct of the database. I believe that is the case in Unidata. A SELECT returns a list of IDs. That's why your recommendation was confusing me. In the Unidata environment, I would have to read every record in order to apply the filter in the loop. In a case where only a few records are selected from a large file, this would create a lot of unnecessary disk activity. Also, you would not be able to SORT the order of the IDs. Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
