Great thing Dave. Roughly having a bound function f that user provided say in an ajaxButton call.The function f may hold references to other functions, session/request-vars, references to the snippets instances etc. One condition is that every object in the graph should be serializable and that is beyond our control (but more on the programmer's control). Of course for the function f to be correctly applied on any node, the whole object graph should be replicated among cluster nodes).
Now assuming that we can serialize any function/object on the wire there is still one thing to solve. As you know LiftSession and HTTPSession are not the same things. a LiftSession is linked to a HTTPSession so we'd probably need to replicate both? Systems like stax have their own way to make a HTTPSession available to any cluster node AFAIK by saving it into a database. Into such environments I'm not such if we know the actual machines identity andif we would have built our own replication system in a clustered env. that would probably not work ... so a node to node replication system may not be possible in stax like environments but would certainly work on other models. Still persisting a LiftSession in DB shoud and sounds like it is more environment agnostic. In a glance node-to-node session replication sounds to be a little more efficient that DB session store we should probably keep an eye on both models. Other model that could be to lazily replicate sessions across cluster nodes such as: 1. Upon a request Node A advertises to other nodes that it hods the last state for session X 2. Upon a subsequent call that hits node B it won;t have the session but it would know where the session exist a fetch the state from that node 3. Node Node B advertises that it has the last state for session X ... Such model is not very fail over proof as at a given point in time different versions of the session state which may or may not enough. The most consistent model seems to be to store the session context into a centralized session store ... but that would induce a single point of failure unless the session store itself is redundant. Last but not the least Java serialization is sub-optimal but I'm not sure how many alternatives we'd have in order to make sure that we have a consistent reference graph that can be represented on the wire.. Br's, Marius On Aug 22, 5:25 pm, David Pollak <[email protected]> wrote: > On Sat, Aug 22, 2009 at 2:31 AM, marius d. <[email protected]> wrote: > > > Greg/Viktor, > > > We could meet and discuss using whatever means (skype, chat, mail > > etc.) and brainstorm what can we do about this. Even though I like a > > lot sticky sessions idiom it is not enough and I think we do have a > > consensus here :) ... of course any committer is more then welcome to > > participate. > > On the substance point (I've moved this to the Lift list), we may want to > use some aspecty thing to analyze the potential serializability of functions > that are added to the LiftSession. I'm betting there's no actual barrier to > serializing stuff in the normal case except when things refer to the > HttpServletRequest (which refers to input/output streams). If we could get > an actual analysis, we could develop a better serialization/session moving > strategy. > > > > > > > Br's, > > Marius > > > On Aug 22, 12:15 am, Viktor Klang wrote: > > > On Fri, Aug 21, 2009 at 11:12 PM, Meredith Gregory > > > > > wrote: > > > > Marius, > > > i really do want to go over lift's ability to > > > > work in vendor supplied clustering solutions. > > > > We could do a Skype conf when you're feeling better, Greg. > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
