On: Close Encounters of the Java Memory Model Kind

[Roboprog]

And then you call something that, unbeknownst to you, updated some shared state like a singleton.

I like your rule #1.

(But I do Java server programming so I can put the kids through school, so, "Damn the torpedoes! Full speed ahead!")

[syngrog66 → Roboprog]

> And then you call something that, unbeknownst to you, updated some shared state like a singleton.

that would mean one has violated rule 1 and 2. the challenge is that it seems to be rare to find programmers who can nail rule 2 downward. (though they do exist.) thus... rule 1. agreed. :-)

flashbacks to fixing dozens of race conditions and thread leaks back at a major travel ecommerce website...

[Roboprog → syngrog66]

I've had the same "flashback" for a financial account site I inherited. Offshore work done in a hurry...

In fairness, though, it's hard to constantly be on your guard NOT to EVER update something that might be visible to another concurrent request. It's interesting that the MS web app model for .NET was to make a new instance of the service code for a page for each request, to at least avoid this problem the moment you "walked in the front door".

TL;DR:

    shared.setState( "Oops!" );