Re: Cookies and Clusters (Cookies)

[\(Home\) Dan Connelly]

I will reply to Malcolm Davis in two parts: Cookies, then (later) Clusters:   Cookies:   Yes, my presentation of the DHTML and JS stuff was a bit confusing.  And unnecessary.   Let me boil it down.     What I was musing about was a hack (??) I had just seen in a non-Struts MVC app whereby the current page gets updated, in situ, through the cookie(s) that head-up an SC_NO_CONTENT page just sent from the server.  The JavaScript in the current page reads the cookie(s) and updates its own document model.  No screen flash.  Very smooth.  A nice MVC screen effect.  Think of the Color Chooser, the canonical MVC application.   Smooth updates.   Is it a hack?  Would we consider such a technique for Struts?   Of course, having the client code read cookies might be considered weird.  But why not.  This is the web.  We survived the frameset mish-mash.   Many B2B apps have captive clients on dedicated PCs.   If the app wants cookies, he should get cookies, right?  These are session cookies, not persistent cookies.  Privacy is not a big concern.  If the browser is loading up on cookies from other apps and maxes out, he gets a nice warning to quit screwing around.   I did not write this MVC-ish app that I am talking about.  I am merely testing it, aggresively, looking for hacks.   I don't have access to the servlet code but I can see the cookies arriving at the browser.  No JSESSIONID there.  Just 4k of encoded state.   You ask, does this app use HttpSession?  Apparently not.  It bakes its own cookies, complex cookies.    Bad.  Bad.  Bad.    But I like it.   It contributes to MVC.  Why not do it, do it, do it??????   ----- Original Message ----- From: malcolm davis To: [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:47 AM Subject: RE: Cookies and Clusters Dan,   > Cookies get a lot of bad press.  But, cookies (or complex URL encoding) are the fall-back > when session beans are not going to be  used.   Many JSP developers will shun session  > beans because the app might get deployed on clustered servers (reverse proxied).   > Each POST might then be dispatched to a different JVM.  Session beans were not shared  > correctly among clustered JVMs until Servlet 2.3.  (Correct me if I am wrong.)    > Nobody is there yet in the commercial offerings.   iPlanet does, and I'm sure other vendors do also.   I'm a little lost here about the DHTML & JS stuff, but you might have a misunderstanding about cookies.    You can turn cookies off in the browser, but the Appserver should implement them via the jsessionid.  Cookies are fine for a cluster environment.  The servlets must be marked as sticky, meaning each subsequent request will return to the correct JVM.  Of course, this might depend on the Appserver being used, and how your cluster is configured. At my present job, we have 3 machines running 10 JVM’s, a total of 30 JVM’s in the cluster. If your not using session beans, are you using HttpSession?   - malcolm