I'm wondering if we can't leverage JavaSpaces to handle a lot of this stuff. From my experience with the technology it seems to be a pretty good fit for the problem.
On Sun, Aug 23, 2009 at 11:06 AM, marius d. <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
