Hi, We are starting the implementation phase of a sizable custom social networking project and find the Stripes Framework thus far extremely appealing for someone that has been architecting and developing Java applications since Java's early days... i.e. someone that may be considered old school :-)
We will have a total of total of 8 application servers (GlassFish 3.0) s/w load balanced over 4 virtualized containers (Solaris 10 zones) on 2 servers. Due to 24-7 usage (yes the system will be accessed in 4 continents), rolling upgrade requirements, using a s/w vs. h/w load balancer, etc... we had to re-think the luxury of having "stickiness". Not to mention that "stickiness" has other less subtle issues like being at odds with HTTP 1.1 keep-alives and eventually one realizes they simply have to disable keep-alives and lose the performance benefits it affords. All this to say that "sticky sessions" like any solution has both Pro's and Con's and that is not something I want to debate. With that said one area we would like to handle differently going forward is NOT utilize "server affinity" aka "sticky sessions". We are planning on using cookies (with security measures for tampering, etc.) to persist data objects stored on the ActionBeanContext. Q1.: Has anyone utilized Stripes in this way? Q2.: Any thoughts / considerations / gotchas on NOT using "sticky sessions" with Stripes? Q3.: Besides the objects that we write to the ActionBeanContext are there any other things in the Stripes framework that we need to be aware of that we need to persist somehow? Q4.: Any structures that Stripes persists on a user "session" (I doubt there are any but ya never know)? BTW we are looking at Stripes 1.5.3 with JPA + Hibernate + Spring + Lucene + etc... Thank You, --Nikolaos ------------------------------------------------------------------------------ _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
