stumpf@gtenmc.UUCP (Jon S. Stumpf) (03/06/90)
Has anyone ever had locks on resources that were left unlocked due to processes that abnormally exited? This would effectively deadlock processes waiting on the resources. I am running Informix Turbo 2.10.3 (as reported by isql). A simple program that can show me that tbinit fails to clear locks or maybe a recount of an event that happened at your site is what I am looking for. Thanks in advance. -- jss - Jon S. Stumpf
aland@infmx.UUCP (Dr. Scump) (03/21/90)
The following commentary is my own and in no way represents any official opinion of Informix. >In article <370@mtndew.UUCP>, friedl@mtndew.UUCP (Steve Friedl) writes: >> >> Oh boy. Turbo uses a shared-memory interface that lets all the >> various processes talk to each other, and it is remarkably >> easy for a process to go away and leave things locked. We use >> ISQL on the 3B15 with a similar shared-memory setup and we have >> no end of problems with it. Steve, I think that you are mixing two completely separate issues here. The original poster had asked about Informix-Turbo. The "similar shared- memory setup" that you refer to here has to do with the shared memory version of the standard engine (SE), which is a *completely* different animal. Also, if I remember right from prior conversations, you were working with shared memory SE as early as the 2.00.03/5 releases, which did have acknowledged problems in the 3B15-specific assembler code. Are the problems that you refer to present in the most recent version (2.10.03K on the 3B15, I think) ? In any event, those particular problems with locks on detaching processes did not apply to Turbo. In article <2314@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: >Oh boy is right. I just took a new job where I will be doing much coding >in C and ISQL. I worked extensively with the product for about 2.5 years over >2 years ago. Lots of problems. Interesting how some things never change. >When my new employer said they were having a hard time getting people who >know UNIX, C and ISQL, I think he meant "getting people who WILL WORK IN >ISQL". >-- >Mark J. DeFilippis begin flame; Jeez. "Lots of problems" in ISQL. O.K., whatever you say. In any event, if you want to post random flames about a company, fine, this is a public forum. However, to submit such a response to a sincere question a user had about a particular product (Turbo) with which you have no experience (as you stated to me in a phone conversation during the time you were working with ISQL 2 years ago) is, in my opinion, irresponsible. If you have since worked with Turbo and encountered genuine bugs in it, I apologize in advance. commit flame; >UUCP: philabs!sbcs!bnlux0!adelphi!markd -- Alan S. Denney @ Informix Software, Inc. "We're homeward bound aland@informix.com {pyramid|uunet}!infmx!aland ('tis a damn fine sound!) ----------------------------------------------- with a good ship, taut & free Disclaimer: These opinions are mine alone. We don't give a damn, If I am caught or killed, the secretary when we drink our rum will disavow any knowledge of my actions. with the girls of old Maui."
endrizzi@sctc.com (Michael Endrizzi ) (03/22/90)
Hi,
I hope I haven't sent this questionaire to you already.
Ignore it if you have seen it already.
On the net I noticed that you work for Informix.
I have a couple questions that perhaps you could
answer or pass on to someone who would know more.
My professor and I are doing research in fault-tolerant
information recall. This means that a data base query
will always recall information in the presence of
faults. If data is corrupted in the query and/or data
is corrupted in the database, searches will always
return the "best" match.
We have developed an SQL RDBMS prototype that
exhibits very high recall rates (high 90% for single
errors). We feel that this technology could be very
useful in OLTP systems (airline reservations, library
searches, law enforcement, banking, financial) where
human users under pressure tend to make mistakes and
create corrupted information. This technology also solves
problems associated with corrupted foreign keys in
Join operations.
My questions are:
1) Have you ever heard about this type of
technology before?
2) Have your customers ever asked you about
this capability
3) Do your products address the problems
associated with corrupted information?
4) Do you feel that working with corrupted
information is/will be a problem as the
need of OLTP grows.
5) Would your company be interested in this
technology?
I would appreciate any help you could give me in answering
these questions. Thank you for your time.
Dreez
=================================================================
=================================================================
Michael J. Endrizzi
Secure Computing Technology Corp.
1210 W. County Road E #100
Arden Hills, Mn. 55112
endrizzi@sctc.com
(612) 482-7425
*Disclaimer: The opinions expressed above are not of my employer
but of the American people.
=================================================================
=================================================================