Changed the thread subject ... Marius
On Aug 22, 6:17 pm, "marius d." <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
