On Sun, Mar 14, 2010 at 7:59 PM, Les Mikesell <lesmikes...@gmail.com> wrote:
> Adam Lee wrote: > >> well, it depends on what you mean by scalability... i'm personally of >> the opinion that traditional sessions should be avoided if you want to >> truly scale. > > > And yet, everyone wants dynamic pages custom-generated to the user's > preferences. So how do you reconcile that? You can help things a bit by > splitting pages into iframe/image components that do/don't need sessions, > and you can make the client do more of the work by sending back values in > cookies instead of just the session key, but I'm not sure how far you can > go. > Basically - yes. For true scalability avoid sessions. Though, I'm still looking for a way to create a so called *stateless*, but "dynamic" ecommerce application that supports multivariate testing, behavioral targeting and all the other stuff the marketing *needs* to have. The thing is that you can't avoid state, the question is where to keep it. So IMO there's no stateless application, perhaps a stateless server side, when state is hold on the client. But these approaches also have disadvantages (security, data/content size etc.) and if you need to support users without cookies it's getting even harder. And POSTing every request to transfer state in hidden form fields is also not nice. These days I stumbled over play (playframework.org out of my head) which says to keep things stateless, I want to have a look at what can be done with this. So, if you have a solution how to build an application without server side session that still matches these other conflicting requirements please let me know! Cheers, Martin > > -- > Les Mikesell > lesmikes...@gmail.com > > > -- Martin Grotzke http://www.javakaffee.de/blog/
