| Date: | May 24, 2007 / year-entry #185 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070524-00/?p=26713 |
| Comments: | 28 |
| Summary: | One of our line-of-business applications sometimes gets very heavily loaded, and several times a day, when you try to issue a query or update a record, you'll get the error message, "Unable to contact middle tier. (other technical gibberish goes here)". Whenever this happens, I like to amuse myself by shouting "Stupid middle tier! We... |
One of our line-of-business applications sometimes gets very heavily loaded, and several times a day, when you try to issue a query or update a record, you'll get the error message, "Unable to contact middle tier. (other technical gibberish goes here)". Whenever this happens, I like to amuse myself by shouting "Stupid middle tier! We should just get rid of it. It's always unresponsive." Of course, this is a joke along the lines of changing that 15 to a 1. The system follows the standard three-tier model. Getting rid of the middle tier won't actually fix anything. But if the error message keeps blaming the middle tier, then to a naive user (or in this case, a willfully stupid one), getting rid of the problematic component might not sound like that bad an idea. |
Comments (28)
Comments are closed. |
That LOB app is one of the rare bad memories I have from MS.
It also liked to overwrite the text size registry key for IE. The dev team for the app never fixed it, so instead IE changed the registry key it used or something equally as …
Poor guy, one day you’ll get the resources to be a real app.
willfully stupid. It needed typing again.
From such seeds are born "fixes" like "just delete tier2.dll" :)
Of course in some applications there may be a benefit to changing a 3-tier system to 2-tier model…
Of course in some applications there may be a benefit to changing a 3-tier system to a 2-tier model…
It is the middle tier. The predecessor of this app connected directly to the SQL database and was much faster.
While we’re on the topic of things Dilbert’s boss says, I present this gem from a Slashdot post (complaining about UAC prompting you about everything):
"I don’t need a warning when I’m installing an application. I know that I’m installing an application."
(Not Responding)
James: That example is precisely why the term "multiple redundant single points of failure" was invented.
If one of them doesn’t fail, another one will step in and make sure SOMETHING fails…
Justin: If you ARE actually installing the application, then of course you know that you are installing the application.
Where UAC helps you is during a drive-by rogue program download from a Web site, or from an e-mail, or something equally bad, when you are NOT (purposefully) installing an application.
If you go to a Web site and UAC warns you that you are installing an application, and you didn’t intend to, THAT’s when UAC can save your bacon. UAC can’t read your mind.
I can’t believe this got from a lighthearted post about the middle tier to a discussion of the merits and drawbacks of UAC in only seven comments.
Raymond – I feel sorry for you. At least nobody reads my blog so I don’t get any comments.
Isn’t "drive-by" the lame excuse from IE folks that unintended malware installations are unavoidable? Well, at least for IE they are. Strange enough no "alternative" (read: real, serious) webbrowser has such problems…
And then on to IE-bashing in only 13… do people have nothing better to do?
Well you can consider UAC as a middle tier, right?
Several times a day it is in the way of what you are trying to do.
It estabilishes a dangerous notion of "computer not trusting the user".
"From such seeds are born "fixes" like "just delete tier2.dll" :)"
Well, nuking verclsid.exe seemed to improve matters greatly :-)
I’m reminded of a few recent outages at work caused by multi-tier setups; someone seems to have forgotten that when you have multiple servers each as the sole provider of a given function, you’re actually *adding* potential points of failure, making the service less rather than more reliable. (Result: one webmail server, relying on one mailbox store for any given user, relying on another single server for SMTP relaying… Not good.)
The point of having a multi-tiered system is so any piece can be replaced independently of the others, no?
Therefore you should definitely get rid of that middle tier – and replace it with something better.
Just stating the obvious….
Of course, the real problem with this LOB app is its unhelpful error messages. Since nobody knows what the middle-tier is, it should just say something like "can’t connect to database X", with the technically-correct but useless error code in some "more info" pane.
But, internal-only applications rarely get the resources for this type of polish, even if it creates headaches for the internal helpdesk.
Blaming the middle tier reminds me of a former job where most of the users on our NT network were convinced that it was "Dr. Watson" that made their programs crash.
They kept asking us to uninstall Dr Watson.
This can get worse: imagine that the mentioned Dilbert-esque, point-haired boss gets this message and orders the middle tier to be removed.
In more than half the places I worked, the middle tier *would* be removed, no matter the consequences…
I would bet that removing the middle tier WOULD resolve the issue.
In every architecture I have ever seen, the service tier only added performance and reliability problems.
When pressed, the developers could never explain the requirement for a service tier other than it allowed them to use some new buzzwords or it allowed them to justify their own jobs for years while they toiled on it trying to make it performant and maintaining it. "Oh, add a column to the database? OK I just need to change and re-deploy all 3 tiers and update the translation and mapping logic. Hmmm lets say 3 weeks dev time because there are so many touch points.".
"UAC can’t read your mind."
But it *should* be able to tell when *I* click on something as opposed to something else running/clicking on something.
@ICR:
"But it *should* be able to tell when *I* click on something as opposed to something else running/clicking on something."
… Why yes, I actually would like to see some pictures of female celebrity of the week. *click*
El Guapo: ""Oh, add a column to the database? OK I just need to change and re-deploy all 3 tiers and update the translation and mapping logic. Hmmm lets say 3 weeks dev time because there are so many touch points.""
The people saying that have badly designed communication between their tiers and/or poorly thought out data handling code in the middle tier. They should try working for my boss for a few months. After he’d fired one of the team for telling him it was impossible to change the database schema in the day he was allowing for the task, I think the rest of them would rethink the design of the system PDQ.
Kuwanger: systems with the level of granularity you talk about have been created in the past. Err… it’s been a while since I looked at the case studies so I’m not sure this is the right system, but you may want to look up an OS called “CAP”. The general problem is that they’re too hard to manage, because the domain of possible permissions settings is too large.
—"that it was "Dr. Watson" that made their programs crash.
They kept asking us to uninstall Dr Watson."—-
There’s one program I knew that wouldn’t run if you had Machine Debug Manager running (which happens automatically with many installations of Office).
You disabled MDM and the program worked fine, bug and all.
I think Raymond’s post was about unhelpful error messages, not about the relative merits of n-tier architectures (which, by the way, have nothing whatsoever to do with "single points of failure").
It sounds like that error message was written either by someone who got a little over-excited about *having* a middle tier, or by a disgruntled developer unhappy about having to rework the entire application. I guess it’s not all that much worse than "the service is unavailable", though.
[ICR]: "But it *should* be able to tell when *I* click on something as opposed to something else running/clicking on something."
Unfortunately, the way >90% of installation programs work is that the .exe file contains compressed data, which the install program uncompresses into a folder, and one of the files is either a program that will actually perform the installation (which it runs) or a .msi file (which it opens). So the program doing the installation *isn’t* the program you clicked on. While UAC *could* do what you ask for, there really isn’t a lot of point as it would hardly ever achieve the results you want.
@Frandsen: ‘… Why yes, I actually would like to see some pictures of female celebrity of the week. *click*’
So, UAC isn’t about control but about protecting idiots from themselves? As was previously said, giving users (and not simply things that can act as users) actual control over the OS is a much better approach than trying to rely on gates to block “bad stuff”. While I’ll admit that I don’t know of a fool-proof system to this (as I try not to underestimate the ingenuity of fools), something like UAC is a hack that’s too obsessed with maintaining backwards compatability, even if it means not moving towards a more optimal solution.
Or, in short, UAC as a middle tier doesn’t help if the design of the lower tier is crap*.
*And just to let you know that I’m not picking on Windows, all modern OSs suffer from a paradigm problem of granting programs power through users instead of giving users the power to grant programs power on a per-program basis. Hacks like creating new user accounts to compensate doesn’t really count. There’s simply a lack of access granularity available in modern OSs, but then that very well might be because people are unwilling to devote the time and energy (or rely/pay-for the time and energy of others) necessary to provide the desired granularity and hence no “complete” OS exists to compete; or people might just not care enough. In any case, UAC as a midle tier isn’t the problem.