See intermixed.
On Mon, 13 Sep 2004 11:34:17 -0400, Dan Allen <[EMAIL PROTECTED]> wrote: > This nice thing about examples is that they are so clean and pretty. > The real world just hands you a shovel and says "Start moving this > horse crap." > > I have an application in which there are a handful of parameters that > are required on each page, regardless of its content, to represent the > general state of things (maybe needed now, maybe down the road a bit). > Such parameters include user id, preference filter, section of site, > and so on. The way things are currently done to handle is baggage is > to just pass it around wherever a form or link is used as a "extra > params" or "hidden fields." > > Now, I consider myself a "Pragmatic Programmer" and I am smart enough > to recognize that this smells really, really bad. It violates several > principles, including DRY and non-orthogonal. I also believe I have a > solution, but I want to discuss it here. > > My thought would be to initialize a state object and put it in either > the http session or a session bean and then each page can work with > this state object as a general filter when executing business logic. > This way, each form and link will be just the core data needed for > that particular request, without all this general information. The > state object would either be initialized on an entry action or at the > start of every action, depending on what is feasible at the time. > > Now, I haven't done this so far, because my manager (use the term > loosely) told me that using http sessions will cause server affinity > in a cluster. If http sessions are out, I suppose I could lean > towards session beans. First I would like to challenge his point on > sessions, and if that doesn't pan out, discuss if stashing this in > sessionbeans is the right way to go. Whether using sessions causes server affinity or not is going to be an architectural property of the particular app server you are using, and may or may not be something that can be configured. However, I could certainly see why an app server would want to implement things that way -- the specs *do* require that, if simultaneous requests for the same session happen, they must all be handled on the same server. In other words, sessions can only be migrated "in between" requests. You'll get better performance if sessions are (at least temporarily) sticky to a particular server instance. Whether server affinity is a problem or not depends, again, on the implementation of your particular app server. If it's something simpleminded like Tomcat's "load balancer", where a session stays on its original server "forever", you could run into scenarios where the load is artificially unbalanced between servers, simply because a lot of the current users happened to create their session on one of the servers, while others remain idle. It shouldn't be as big a deal in an app server environment that actually balances load by moving sessions around, or if your sessions tend to be relatively short so that imbalances tend to go away quickly. By the way, even if you stash data in session beans, you'll need to provide some mechanism for the subsequent request to identify and retrieve which session bean is relevant. You can continue to use hidden fields for that (but you only need one), or you might think about using a cookie so that the browser does the work of forwarding the correct identifier back for you. > > Dan > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
