steve@tellab1.UUCP (Steve Harpster) (10/11/85)
>From: tellab1!ihnp4!mhuxn!mhuxr!ulysses!allegra!oliveb!bene!luke!bob >Article 3203 of net.micro.pc: >Relay-Version: version B 2.10.2 9/5/84; site tellab3.UUCP >Posting-Version: version B 2.10.2 9/5/84; site luke.UUCP >Path: tellab3!tellab1!ihnp4!mhuxn!mhuxr!ulysses!allegra!oliveb!bene!luke!bob >>From: bob@luke.UUCP (Bob Speray) >Newsgroups: net.database,net.unix,net.micro.pc >Subject: Re: Unify Database Problems >Message-ID: <340@luke.UUCP> >Date: 10 Oct 85 00:59:43 GMT >Date-Received: 10 Oct 85 17:06:17 GMT >References: <293@tellab3.UUCP> >Reply-To: bob@luke.UUCP (Robert Speray) >Organization: Benetics Corp, Mt.View, CA >Lines: 88 >Xref: tellab3 net.database:81 net.unix:3518 net.micro.pc:3203 >Summary: > >In article <293@tellab3.UUCP> steve@tellab3.UUCP (& Harpster) writes: >> >>The following is a memo written by a co-worker describing the problems >>we have found with the Unify database system. I thought it would be >>of general interest. > >The quoted memo was a real indictment of the Unify dbms product. >"Problems with Unify", "major flaws", "irritating bugs". >Its tone was -massive troubles with that Unify system-. > >This response is to balance the thrust of the original memo. >Unify does not have the "major flaws" that were claimed. > >record locking? WHO has this problem solved on Unix? Every variant >solution around has its limitations. Unify uses John Bass locking >in our environment( Plexus P60, sys3) - an absolutely exclusive lock that >locks out reads as well as writes. It works fine, AS DEFINED, but >has severe limitations on concurrent reads. It's ok for concurrent writes. In all fairness, record locking is available in system V (minimally in 4.2BSD). The UNIFY that I was discussing in the memo had to do with the implementation available on the IBM PC/AT. UNIFY specifically advertises that their product is capable of record locking, and for multi-user access. I have found that the only way (on the AT) to preserve the database is to provide a semaphore around all database accesses. UNIFY support told me that this would NOT fix any database corruption trouble, and that is obviously not true (it has). > >Unify not checking itself? I think this describes the documented misuse >of access/gfield. You request a record by key without checking the >return code, then attempt to get data out of the record. The gfield >call aborts because there is no record to get data from. You want Unify >to check that the record exists at the gfield call and return an error >code to you then. You didn't look at the return code after the access. >You've got an application bug. Not true. The applications that I talked of DID check all responses from the database, and reported those errors back to the main controller. Again, this problem was due to the database not successfully locking out multiple processes correctly. The access was coming back that the record was there, but when the gfield was done, it couldn't find the record again. When semaphores were added, most of these problems went away. > >poor error recovery? Unify returns error codes for recoverable errors and >exit(99)'s on non recoverable errors. We had a similar criticism but learned >that non recoverable errors were of two sorts - corrupt database or >application program error. Both type errors should disable continuation >of a process in a production environment. Unify does define a way to load >local error handling routines but they should never return, only exit. >Our error handling routines produce a core dump on the way out. What we were trying to report was the fact that a corrupt database was occuring much too often, and our database needs are such that we need reliability. In this application, when a database DOES become corrupted, the application must recover by rebuilding the database some way. An exit(99) not only doesn't report exactly what's wrong, in doesn't fit our needs. Agreed, we can replace the error routines provided by UNIFY. > >underscores in field and record names? A real bug. Supposedly fixed >in the latest release. > >no b-trees on combination fields? Yup, just as defined. A limitation >of course. > >limit of 9 digits in numeric fields? Only on display, using Unify screen >utilities. The data is stored as a long and contains valid values. >This display limitation is a bother. These are all "limitations" in the database that have no excuse for being there. None of the problems listed above are catastrophic, but this IS version 3.0, and they should have been rectified by this time. Other database products do NOT have such limitations. > >different calls for reading first record and for reading rest of records? >This observation is similar to the observation that Unix defines >different calls for opening a file and for reading it. >Is this a valid criticism? The observation is quite different, since opening and reading are two different things. I believe you mean the case of creating a file vs. opening a file. That too was bogus, and 4.2BSD fixed that problem; when you open the file it will be created (by specifying the O_CREAT flag) if it doesn't exist. What difference does it make if I'm reading the first record or any other record? Why not have a single routine to read a record? > >records stored in random order? I don't understand this point at all. >The phrases, "long delays when searching back in time", must refer to >a particular function that takes a long time to run. I don't see the >connection to record storage strategies. We were given the impression that UNIFY stored records in a B+ tree. Record storage IS important when quick retrieval is a must. Long delays to find the one record that I am looking for is not tolerable in our application. > >sorting and searching routines don't work? We use some of the sorting >and searching routines and have no trouble with them. A simple test >program that doesn't work properly demonstrates a bug in Unify or >a bug in the application. Seems straightforward to discover the fact >of the matter. Again, we have done exactly what you suggest; All the test program did was count how many records were in the database. I checked the result of the program by using SQL to do the same thing, and I came up with different numbers. I then entered UNIFY and did an inquiry on the record and got the same answer as the SQL. The program was only about twenty lines long. It did not work the way that the manual described that it would. I still haven't been able to get the function unisort() to work. I keep reading the documentation, I build the table of functions as they describe, and it still gives me a segmentation violation. I KNOW that I am not using the function correctly, but its the documentation that is giving me a headache. If examples of code were given, they probably wouldn't have half the calls that they have. > >you claim you've discovered a bug in the Unify record locking implementation? >and Unify support wants to see your test program in order to duplicate >the problem? so what's the issue? "ha ha, i found a bug but i wont help >you fix it cause you don't think there is one." The issue is that I am currently working on proprietary information that my company does not wish to divulge at this time. I described exactly what I was seeing, worked over several days with their support personel via telephone, and had about 15 core dumps that I sifted through. I feel I helped them as much as I could to discover their problem, but when I added the semaphore to our code and showed that the problem disappeared, they told me that nothing had been proven. I have a product to produce; I don't have enough time in the day to do my work and hold somebody else's hand too. UNIFY contended that it MUST be something I am doing, and not their code. Fine. There are other databases available. > >poor support? Sounds more like a personality conflict. > >I'd prefer support persons who are highly qualified >programmers, intimate with the coding details of the system, and anxious to >find bugs in the system and correct them, but I'll accept someone who >listens to my problem, conveys the problem to the development staff, >and follows through with a recommendation to me on how to continue. >Our interactions with the Unify support office have been adequate. I would accept that too. I had core dumps showing where they did a divide by zero, and the support staff didn't even want to know what routine did it. I talked to engineers (not the first level of support staff) at UNIFY that did not understand the basics of UNIX. Our application is a series of processes that interact via shared data segments. Trying to describe how the system operates becomes very difficult when the support individual doesn't understand how shared data works, how semaphores operate, and why file locking is NECESSARY in a multi-process environment. After the amount of discussion I had, I came to the conclusion that they were not capable of helping me with my problem. It could be that I just reached the wrong individual; what people do you work through? > >Are there real problems with Unify? We have been using Unify >for several years now in a complicated multi-user application. >We have discovered some unusual aspects of Unify but have been >relatively happy with the product and the support. > >In fact Unify provides the best dbms product in the Unix >market for our application, by far. We have 150+ record types >in our schema, 200Mb of data, and a stringent response time requirement. >Other vendor products might be ok for other applications but none I know of >can provide this capacity or performance. > >Robert Speray >Benetics Corp > I don't disagree that UNIFY has applications; I was only stating that my experience with UNIFY on an IBM PC/AT was not adequate for my particular application. Unfortunately, I have not seen the performance that you obviously have seen with UNIFY. It could be the implementation, it could be the particular hardware. In any case, I felt that there were enough problems that I should notify other users so that they could find the best product for their needs. I wish you continued good luck in your application. Michael F. Skowronski Tellabs, Inc.