Fwd: IIUG 2008 survey for new features
Not a technical support thread but an argument sparked by the IIUG 2008 new-features survey. Daniel Morgan claimed IDS was only now getting deadlock detection, which other RDBMSs had long had. Art Kagel, Andrew Ford, Fernando Nunes and others corrected him: IDS has detected deadlocks for many years, returning ISAM error -143; the survey item was merely a request to automatically capture detailed session/query information about deadlocks so DBAs can trace the offending applications. Deadlocks were also characterised as an application-design issue (e.g. always updating tables in a consistent order). Beyond this clarification, the thread ends in a vendor flame war with no further resolution.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Daniel,
I try to ignore your rants, I really do. They are uninformed and typically
sophomoric. However, every once in a while, I give in to temptation.
On Wed, Oct 8, 2008 at 11:02 AM, DA Morgan <damorgan@psoug.org> wrote:
> Obnoxio The Clown wrote:
>
> > I've never seen a deadlock in 20-odd years. Maybe Oracle programmers are
> > just shit?
>
> Or perhaps you work on systems, for example embedded, where there is
> only a single user.
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? I managed over 40 IDS servers serving 400,000+ users of
hundreds of applications and dozens of databases for 14 years at Bloomberg
and never once did we have a single deadlock timeout or rollback in
production. Is that multiuser enough for you.
Primarily we didn't see deadlocks because we almost exclusively ran in-house
developed software written by well trained and disciplined programmers.
Bottom line, deadlocks are a development/developer problem not a server
problem, so I'll go with OTC's position that Oracle programmers may be -
never mind I'll leave the mild profanity to the my good friend OTC.
What was proposed in the survey, and since I'm on the BOD I can speak to
that, is a proposal to increase the level of detail of information available
about which sessions and queries triggered the deadlock condition so that
DBAs can go beat developers and software vendors over the head to get the
causes fixed in their applications. Deadlocks are mostly experienced in
shops that run third party software in combination with home-grown
applications and tracking down the interactions between known source
in-house software and third party apps that are mostly black boxes is key to
smooth operations.
>
>
> Don't rag on Oracle about your problems. It was proposed in the survey
> as a NEW feature for IDS. Obviously someone needs it? And equally
> obvious it doesn't exist even though it is present in the market leading
> products.
As to your list of features in Oracle 'forever', "it is to laugh!" You
don't want me to produce a list of features that IDS has had 'forever' that
Oracle still doesn't have or that Oracle added many years after Informix
Online and IDS introduced them to the industry (including the ability to
ALTER a table at all let alone to alter them in-place and a functional
on-line archive system).
BTW, as OTC pointed out, the feature about the dbaccess LOAD verb making
partial commits isn't strictly needed, as OTC pointed out. All of the
external load utilities which are delivered with IDS include this feature
and several can be used instead of LOAD and tend to be faster as well. The
question was included simply because it was a frequently requested feature
from users on the Informix forums and the other sources the survey committee
used to develop it and the IIUG board represents those users. If you/we
mostly think that a feature is needed we'll present it to IBM. The purpose
of the survey is to find out what's important to the user community and how
important each feature is.
Art
>
> --
> Daniel A. Morgan
> University of Washington
> damorgan@x.washington.edu (replace x with u to respond)
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
Art Kagel wrote: > Daniel, > > I try to ignore your rants, I really do. They are uninformed and > typically sophomoric. However, every once in a while, I give in to > temptation. > > On Wed, Oct 8, 2008 at 11:02 AM, DA Morgan <damorgan@psoug.org > <mailto:damorgan@psoug.org>> wrote: > > Obnoxio The Clown wrote: > > > I've never seen a deadlock in 20-odd years. Maybe Oracle > programmers are > > just shit? > > Or perhaps you work on systems, for example embedded, where there is > only a single user. > > > 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? I managed over 40 IDS servers serving 400,000+ > users of hundreds of applications and dozens of databases for 14 years > at Bloomberg and never once did we have a single deadlock timeout or > rollback in production. Is that multiuser enough for you. > <snip> sophomoric - Oh yes. Agreed, in previous incarnations as a DBA, I insisted to Developers that "all tables be updated in alphabetical order" - crude but effective. And, ANY DBMS could run into it.
On Wed, Oct 8, 2008 at 12:34 PM, TBP <theBP@usenet-news.net> wrote: > Art Kagel wrote: > > Daniel, > > > > I try to ignore your rants, I really do. They are uninformed and > > typically sophomoric. However, every once in a while, I give in to > > temptation. > > > > On Wed, Oct 8, 2008 at 11:02 AM, DA Morgan <damorgan@psoug.org > > <mailto:damorgan@psoug.org>> wrote: > > > > Obnoxio The Clown wrote: > > > > > I've never seen a deadlock in 20-odd years. Maybe Oracle > > programmers are > > > just shit? > > > > Or perhaps you work on systems, for example embedded, where there is > > only a single user. > > > > > > 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? I managed over 40 IDS servers serving 400,000+ > > users of hundreds of applications and dozens of databases for 14 years > > at Bloomberg and never once did we have a single deadlock timeout or > > rollback in production. Is that multiuser enough for you. > > > <snip> > > sophomoric - Oh yes. > > Agreed, in previous incarnations as a DBA, I insisted to Developers that > "all tables be updated in alphabetical order" - crude but > effective. > > And, ANY DBMS could run into it. Apparently Oracle is more prone to deadlocks than others, though! My sources back at my old stomping ground have informed me that several of the handful of applications that they have ported from IDS to Oracle and some third party apps that were moved from IDS to Oracle when the big O bought the vendor (gee who could that be?) are now experiencing deadlocks frequently! The contacts have also verified that there hasn't been a single IDS deadlock in the 11 months since I left either so that makes 15.4 years without a single production deadlock on any of now 60 some odd servers. OK, maybe this IS an RDBMS issue for Oracle, it certainly isn't for IDS. Art > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
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@x.washington.edu (replace x with u to respond)
Art Kagel wrote: > Apparently Oracle is more prone to deadlocks than others, though! My > sources back at my old stomping ground have informed me that several of > the handful of applications that they have ported from IDS to Oracle and > some third party apps that were moved from IDS to Oracle when the big O > bought the vendor (gee who could that be?) are now experiencing > deadlocks frequently! I see that behavior too. People that move code from a non-MVCC environment to an MVCC environment without learning the differences in architecture and concepts try to move their code without making the required alterations to account for the way the product works. Perhaps your "sources" should consider learning to read docs or take classes rather than stumbling around in the dark making beginners mistakes. The same inevitable errors exist when people try to port code from Oracle to Informix without reading the docs. The reason you don't hear much about it is that no one is moving from anything to Informix. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)
DA Morgan wrote: > 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. > <sigh> If you really, actually knew anything about Informix, you'd know that deadlock detection was there from the get-go. My best guess is that all the demand for automatic deadlock detail capture comes from all the people who are migrating from Oracle to IDS. People who grew up with IDS never had this issue. -- Cheers, Obnoxio the Clown http://obotheclown.blogspot.com
----- Original Message -----
From: "DA Morgan" <damorgan@psoug.org>
Newsgroups: comp.databases.informix
To: <informix-list@iiug.org>
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@x.washington.edu (replace x with u to respond)
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> 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
In article <1223489231.956342@bubbleator.drizzle.com>, DA Morgan says...
>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.
??????????
ISAM error 143 has been around for more than a decade.If I am not mistaken, this has been around since online
5.0, which means for 15+ yrs.
-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.
And we are suppose to believe that you have worked with informix?
DA Morgan wrote: > 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. Yes, this is not about whether or not you know what a deadlock is! This is about whether you can read English or not... As any other RDBMS IDS deals with deadlocks. The feature on the survey talks about getting more info when it happens. This info can allow the developers and/or DBA to alter what's needed to avoid them. Let me copy/paste for you: "Add ability to automatically capture detailed information on all deadlocks" Currently you can capture it by setting a trap. So now, assuming you were able to understand a simple phrase in your native language, do you still have any doubt about this that we can help you with? It's unbelievable that you think in 2008 that IDS doesn't detect deadlocks... about 5 or 7 years after you predicted the dead of Informix as a product, didn't find a bit of time to study the subject before writing totally ignorant comments?! > 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. Because, currently IDS doesn't capture any special info automatically. It just returns a corresponding error. Regards, -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...