Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!bg0l+ From: bg0l+@andrew.cmu.edu (Bruce E. Golightly) Newsgroups: comp.databases Subject: Re: Ingres/STAR problem Message-ID: Date: 18 May 89 13:28:40 GMT Organization: Carnegie Mellon, Pittsburgh, PA Lines: 26 We tried a couple of things that seem to have helped a little. Frankly, what we've done is cheating and may be risky. I got into the STAR data base as if it were a regular data base. This can be done by tacking II onto the front of the data base name. I then manually modified the STAR specific catalogs to their normal structures. This is the sort of action normally taken by SYSMOD. This has resolved some of our problems for the time being. We can, at this point, have several developers working at the same time with FEWER locking problems. A test allowed us to have 4 out of 5 developers successfully working on VIFRED forms concurrently. We're extremely worried about the underlying problem, though. We plan to perform some additional experiments to see if there are other things we can do to eliminate or further reduce the locking problems. Our concern is for the future. What happens when we're got N users trying to retrieve/update data table in this STAR data base? Tolerating locking problems during the development phase is quite different than trying to live with them in production. Some the the planned tables for this application are going to be quite large, and will see heavy concurrent usage in both retrieve and update modes. I'll pass along further developments as they occur. Bruce