• (nodebb)

    This is a good illustration of the difference between "It only needs to have one" and "It needs to only have one". The second might be a singleton-pattern object(1), but the first definitely is not.(2)

    (1) If you subscribe to the theory that the singleton pattern has any value, which I mostly do not.

    (2) It's just an object you only create one of, not an object you mustn't have more than one of.

  • Michael R (unregistered)

    This reminds me when I was working for a financial institution in 2002 (enterprisey stuff ahead) and someone decided to have such a mortgage calculator on our website. Being a Microsoft shop the decision was made that the form-submit starts a headless Excel instance on the server and opens a XLS which takes the data, crunches the numbers, returns the values and shuts down again. When a few customers tried this at the same time the box came to grinding halt and sometimes fell over. Funny days.

  • Michael R (unregistered)

    This reminds me when I was working for a financial institution in 2002 (enterprisey stuff ahead) and someone decided to have such a mortgage calculator on our website. Being a Microsoft shop the decision was made that the form-submit starts a headless Excel instance on the server and opens a XLS which takes the data, crunches the numbers, returns the values and shuts down again. When a few customers tried this at the same time the box came to grinding halt and sometimes fell over. Funny days.

  • Hanzito (unregistered) in reply to Michael R

    It's really one of those "if all you've got is a hammer" moments, isn't it? And the solution is obvious: more servers and a load balancer.

  • Hasseman (unregistered)

    Mortgage, a French word entering English: Mort = death, Gage =pledge, sort of meaning pay to death ...

  • BPFH (unregistered) in reply to Michael R

    I've worked with Excel automation before. You're lucky it was that reliable.

  • (nodebb) in reply to Michael R

    Being a Microsoft shop the decision was made that the form-submit starts a headless Excel instance on the server and opens a XLS which takes the data, crunches the numbers, returns the values and shuts down again. When a few customers tried this at the same time the box came to grinding halt and sometimes fell over.

    Good thing it didn't work. In these cases, Microsoft wants Excel licensed to the user that sees the result of the automation. If the license auditor came in and they discovered this (disgruntled employee?), you would be charged one Excel license for every unique website visitor. If you couldn't identify unique users, they would settle for one license for every visit to that page, unless that number exceeded the number of humans on the planet, then you would simply have bought Excel for everyone.

  • Hans (unregistered)

    Been there, had it done to me. We had a web-app that showed some investment-related stuff that worked for various brandings. For calculations data was handed over to a 3rd party app, that used the same branding. Sometimes when control was handed back to us, we got the wrong branding. So of course, it was out fault - they were quite certain of it.

    That is until I added a whole lot of logging to our side and could prove that is was their side that sent the wrong data: Whenever calculations for two brandings were happening, the last one won. So I sent a guess: are you storing that branding in a singleton (or static variable)? I don't think I head anything from them, but the issue was solved.

  • (nodebb)

    I worked at a financial company that hired some expensive consultants to build a web app. It was the J2EE era, so they used EJBs. They finished the app and left, leaving the staff to test and deploy. Stage was a single server. Production was two servers. Once it went live, customers started reporting seeing other people's investments in their accounts, which essentially merged them together in the database. Turns out, the highly paid consultants use Stateless Session Beans, but put state in them. On one server that was OK, but on two servers each one had identical ids, and each request could go to either server, thus mixing up the stateless states. Months of manual editing followed...

  • (nodebb)

    And somehow, the mainframe didn't have this problem. My guess is the mainframe runs COBOL, where there is only global scope, so everything is a singleton...

    Ya, sure, there's Objective COBOL out there, but why ruin a good thing, right?

  • (nodebb)

    Isn't the real problem that the back-end code executed all requests in the same environment, so concurrent requests stomp over each other?

  • (nodebb) in reply to Hans

    I don't think I head anything from them, but the issue was solved.

    When I worked in financial services, we used the phrase "nothing was wrong, and it's fixed now".

    That was a direct quote from our representative at a very large data processing service.

  • Loren Pechtel (unregistered)

    Got burned that way with IIRC a CRC-32 calculator in Borland Pascal. No idea what local state it had but it turned out not be thread safe.

  • (nodebb) in reply to Loren Pechtel

    The current value is usually the state. Things like hash algorithms and CRC calculations start with an initialized state, to which you feed in data. The key part is the state - it means you can either feed in data a byte at a time, a block of data at a time, or the whole thing in one go - you get the same result. But this means it has to maintain an internal state.

    These days, functions have you pass in an opaque structure that contains the internal state to make it thread safe. You initialize the structure, then you pass it when you pass data through it. The state gets updated, then the function returns and you're free to pass more data through it.

    This ability to incrementally update the state is how 2FA authentication works where you often type your password followed by the 2FA code. The server has your password hash, so it then takes the 2FA token value and hashes it starting from the stored password hash. If the two hashes agree then you're let in.

    Of course, older implementations stored the state globally.

  • (nodebb) in reply to Steve_The_Cynic

    I'm giving the hairy eyeball at English right now, in which "all not" and "not all" are apparently synonymous.

  • Tim (unregistered)

    Reminds me of an app I worked on once. It was a typical OO design with a singleton "God" object at the centre which coordinated everything. Unfortunately one of the people working on it didn't understand concurrency and the God object was not re-entrant. The workaround was to clone the god object at the beginning of each HTTP request.

    I never got a chance to see if that workaround actually worked because shortly after that, we realised the app didn't do anything that anyone wanted so the whole thing was abandoned.

  • bappo (unregistered) in reply to Steve_The_Cynic

    If you code a Spring MVC web application you end up with tons of singleton (Spring and not Spring), and since you cannot put any state on them, the fact they are singleton have no real use (after all, if you do not have state, why i cannot have my private instance). Since there is no evident reason on why they are singleton, many developers have no idea of the fact they are, and sometimes you end up with nice race conditions bug like this one.

  • Graculus (unregistered)

    Worked for one of the NHS software suppliers and the "architect" there made the same mistake (duh a patient can only have one patient record so lets make it a singleton).

    But of course this is FAR more serious when it comes to peoples health. The Patient Record was a singleton and so switching between patients you could see the patients details for the last viewed patient...

Leave a comment on “A Single Mortgage”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article