On Tue, Jan 28, 2014 at 8:59 PM, Neven Cvetkovic <neven.cvetko...@gmail.com>wrote:
> On Tue, Jan 28, 2014 at 3:54 PM, Howard W. Smith, Jr. < > smithh032...@gmail.com> wrote: > > > > Thus I will probably never have to use clustering. > > > > Loving your responses on this topic, Chris. I do not want to hijack this > > thread, but i find this topic interesting, and your responses make it > more > > interesting! > > > > > +1. Great discussion, as always :) > > > > Honestly, I don't need clustering (yet) in my app, but I feel as though > > endusers of my app will be fine in a failover situation (as you described > > in this thread). Endusers of my app have to login a lot since I set > session > > expired = 15 minutes. no complaints from the endusers, because they are > in > > and out of the app...all day, (almost) every day. > > > > Ultimately, session stickiness works great to handle load balancing > (workload management), but it is not enough for session failover. In the > unlikely event that the serving tomcat instance dies, the user will be sent > over to the other tomcat instance (that doesn't know anything about you, > i.e. doesn't have your session data), and will probably need to login > again. Now, as Chris pointed out - it would be great to design your app > that it saves the intermediate work to a database or some secondary store > that can be retrieved upon login again. Think "shopping cart", you are > shopping around, the instance goes down, you need to login again, and a > nice application would persist shopping cart for you, not so nice > application would not, so when logged in again - the shopping cart would be > available or not :) > +1 (000,000,000,...) wow, thanks Neven. That was a great thought/analogy right there. As someone that uses amazon.com quite often, I do like the shopping cart feature, even though I have not recognized if my shopping cart was saved across sessions... oh, but you just jogged my memory, and a product that I looked at recently, amazon.com sent that product (and similar products) to my email... so evidently, 'interests' are persisted per user/session. 'not so nice application would not'... wow, i definitely accept that as constructive criticism. thanks. > Now, if your end users can live with that scenario - that's great - no need > for session replication, clustering your instances, network chatter, etc... > It definitely simplifies the configuration and setup. > > However, if your end users (i.e. your Service-Level-Agreement / SLA) do > require a proper session failover, you will need some sort of session > replication to successfully implement that feature. That's not trivial and > depends on the appserver (e.g. Tomcat, JBoss, WebSphere, Weblogic). Session > replication is not part of the official JEE/Servlet spec, but most modern > and serious appservers would provide some way of replicating sessions and > clustering appserver instances. > +1 definitely here for tomcat (a serious appserver). :) > > Now, if you could make you application stateless - you could possibly turn > off the sticky sessions. Makes things very easy to scale! > +1 thanks. even though my app is Java Server Faces app, I would say it is quite stateless in nature/design, since users accomplish majority of their daily tasks via one-page requests. of course, 1. one page is required to login 2. another/one page is required to search/filter/navigate-to target data that already exists in the database 3. another/one page is required to add/update data, or to take some action against that data (print data/form, email data/form to customer, etc...) and this is normal user activity; some users let their session expire after completing steps 1 and 2 above, or steps 1, 2, and 3 above. In reference to the shopping cart suggestion, I would assume that you would suggest that steps 2 and 3, above, are persisted, so users can resume previous session. > :)) > > the only time I really need failover is when I 'might' want to update the > > app's software. the app is quite stable now and not many software changes > > right now, so again, there's not much of a need for failover. :) > > > > Excellent! Keep it simple! > +1 thanks; that's my goal...keep it simple (for the endusers). :) > Good luck! > Neven >
