Don't you just hate it...
2003-03-03 08:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mdlbear...when you discover a serious, pervasive design flaw in your software at 4:30?
It's all because Java doesn't have dynamically-scoped variables. If I'd been writing in Lisp, everything would have been fine.
You see, we have this application, written in Java, for composing messages that are later shipped up to a server to be accessed by the recipients. Naturally, there's a lot of per-user state, that lives in a profile file in the user's home directory. The application sucks in this file (which is a sequence of
All perfectly straightforward stuff. Works great, less filling, nice and efficient... until you decide to allow users with browsers to access a subset of the composer's capabilities running on the server as a servlet.
All of a sudden all this efficiency becomes a problem, because many users might be using the servlet simultaneously, and the system properties are, of course, shared by one and all. Oops!
The reason this problem didn't arise in the existing server code was that it was all implemented as CGIs (each running in a separate subprocess) written in Perl (which has dynamic scoping as an option, so that rewriting it for
Moral: always put your complete processing context into an object, and pass it around explicitly to everything that needs it.
It's all because Java doesn't have dynamically-scoped variables. If I'd been writing in Lisp, everything would have been fine.
You see, we have this application, written in Java, for composing messages that are later shipped up to a server to be accessed by the recipients. Naturally, there's a lot of per-user state, that lives in a profile file in the user's home directory. The application sucks in this file (which is a sequence of
name=value pairs) and puts the pairs into the system properties. Then it merges the overrides from the command line, and uses the result to set up some data structures in a bunch of static global variables where all the code can get at them. All perfectly straightforward stuff. Works great, less filling, nice and efficient... until you decide to allow users with browsers to access a subset of the composer's capabilities running on the server as a servlet.
All of a sudden all this efficiency becomes a problem, because many users might be using the servlet simultaneously, and the system properties are, of course, shared by one and all. Oops!
The reason this problem didn't arise in the existing server code was that it was all implemented as CGIs (each running in a separate subprocess) written in Perl (which has dynamic scoping as an option, so that rewriting it for
mod_perl, which I've always suspected I'd have to do some day, won't be terribly hard.)Moral: always put your complete processing context into an object, and pass it around explicitly to everything that needs it.