I'm not so concerned about the lack of session replication from a scalability point of view. Sticky sessions will get you a long way. Plus I've learned my lesson about over-engineering for scalability before you need to. However, it'd be nice to choose a path that could scale in the rare event it's needed. Stax, lacking sticky sessions, probably isn't such a path for a lift app. It seems GAE also does not support sticky sessions.
If you need seamless fail over or need to do rolling updates, then lack of session replication becomes an issue (btw, I don't need either of these at the moment). Wicket is able to support session replication with its detachable models. The developer still needs to be careful about references when implementing a model's load method, but this is easily done by using @SpringBean to get weak references to Spring proxies. So, what are the differences between the wicket style - binding an anonymous inner class that extends a base component class - and the lift style - binding a function which is really just an anonymous inner class? One difference is that Wicket's base component classes do a good job of reinforcing the use of detachable models. A second difference is that lift doesn't have an easy built-in way to get weak references to unserializable resources such as mapper objects containing database connections. I don't have a solution, but thought I'd chime in since I have some Wicket experience. On Aug 18, 5:44 pm, Meredith Gregory <[email protected]> wrote: > Guys, > > This really seems like a weakness. Can someone walk me through the issues on > the lift committers call, tomorrow? > > Best wishes, > > --greg > > On Tue, Aug 18, 2009 at 1:51 PM, Viktor Klang <[email protected]>wrote: > > > > > > > On Tue, Aug 18, 2009 at 4:22 PM, marius d. <[email protected]>wrote: > > >> On Aug 18, 5:05 pm, Naftoli Gugenheim <[email protected]> wrote: > >> > You set whether you want a shared server, or dedicated/various speeds. > >> > In any case, is there room to entertain the thought of at some point > >> adding support in Lift to propogate sessions across instances? (Is it > >> easier > >> now that it's been decoupled from servlets?) > > >> No it is not easier. The fundamental problem in distributing lift > >> sessions is the bound functions. Sure, functions are serializable but > >> their references may not be. For instance one can bind an ajax > >> anonymous function and that functions can have a bunch of other > >> references inside potentially other lambdas etc. Viktor was doing in > >> the past some research to integrate with Terracotta but there were > >> some issues. So consistently distributing Lift sessions in a clustered > >> environment is a challenge but of course good ideas are more then > >> welcome. > > > Yeah, it really was a can of worms... > > >> > ------------------------------------- > > >> > Ryan Donahue<[email protected]> wrote: > > >> > Is anybody using Stax for anything more than prototyping or examples? > >> > If so, what has your experience been? Stax doesn't seem to fit lift > >> > very well, but I'd like to find out I'm wrong. Specifically, it does > >> > not support sticky sessions: > >>http://developer.stax.net/forum/topics/initial-questions. > >> > I assume a Stax app shares resources with others on the same server, > >> > so you'd likely need to scale to additional servers sooner than > >> > normal. However, the lack of sticky sessions effectively caps a > >> > stateful lift app to one server. > > > -- > > Viktor Klang > > > Rogue Scala-head > > > Blog: klangism.blogspot.com > > Twttr: viktorklang > > -- > L.G. Meredith > Managing Partner > Biosimilarity LLC > 1219 NW 83rd St > Seattle, WA 98117 > > +1 206.650.3740 > > http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
