Re: Fwd: IIUG 2008 survey for new features


----- Original Message -----
From: "DA Morgan" <damorgan@xxxxxxxxx>
Newsgroups: comp.databases.informix
To: <informix-list@xxxxxxxx>
Sent: Wednesday, October 08, 2008 1:07 PM
Subject: Re: Fwd: IIUG 2008 survey for new features


Art Kagel wrote:

Or perhaps you don't know that a deadlock is the result of a poorly
designed set of interacting applications accessing multiple resources in
undisciplined order causing two or more users to lock each other out of
required resources?

You should consider going into politics or selling used cars.

The issue is not whether I know what a deadlock is or the cause.
The issue is that all other major RDBMS products already contain
deadlock detection capabilities that are just now being considered
for IDS as a "new" feature.

If you want to rant then instead of targeting the messenger why
don't you ask yourself why this feature was listed as something
"new" for IDS in the survey? It wasn't my survey ... it was yours.
--
Daniel A. Morgan
University of Washington
damorgan@xxxxxxxxxxxxxxxx (replace x with u to respond)
_______________________________________________
Informix-list mailing list
Informix-list@xxxxxxxx
http://www.iiug.org/mailman/listinfo/informix-list

The feature request is not for deadlock detection, that already exists in IDS. When this situation occurs the clients are returned
ISAM error code

-143 ISAM error: deadlock detected.

The database server has detected an impending deadlock between
your request and other, concurrent user requests. Each user request is
waiting for a resource (a row or disk page) that is held by another
request in the chain; if your requested operation went forward, the
chain would be closed and all requests would be deadlocked. In the
short term, treat this error the same as -107 (record is locked). Roll
back the current transaction, and re-execute it after a delay. To
prevent recurrence, review the design of the applications that use the
same tables and execute concurrently. Various design strategies can
minimize the probability of deadlock.


The feature request is simply to add the ability for the engine to capture detailed information on the sessions causing the deadlock
so one may track down the appropriate developers/vendors and smack them on the head.

To say Informix currently does not have deadlock detection is incorrect and silly.

I'm glad Informix R&D chose to implement geographically redundant RSS nodes before tackling this feature request.

Andrew


.

Relevant Pages

  • Re: Fwd: IIUG 2008 survey for new features
    ... deadlock detection capabilities that are just now being considered ... ISAM error 143 has been around for more than a decade. ... -143 ISAM error: deadlock detected. ... your request and other, concurrent user requests. ...
    (comp.databases.informix)
  • Re: Performance issue of ASP .NET
    ... So from your two response, I got that there're some deadlock info detected from teh Eventlog and you also mentioned that you found there has 4 current request and executing requests stuck on the server, so possibly they're the ones which has run into deadlock, do you think so? ... As you see it's very short period amount of time taken for lock and unlock. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: 2.6.16-rc6-rt1
    ... Try to compile the kernel ... If you have debug deadlock detection enabled it triggers a bug and shows ... You mean that you have to run deadlock detection for all futexes to avoid ... by following the lock chain. ...
    (Linux-Kernel)
  • Re: Performance issue of ASP .NET
    ... So from your two response, I got that there're some deadlock info detected ... request and executing requests stuck on the server, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Deadlock during multipath failover
    ... During multipath failover tests with SCSI on System z, ... the request to the end of timer_list. ... The timer already ... The patch fixes the observed deadlock. ...
    (Linux-Kernel)
Loading