On Wed, Mar 25, 2009 at 7:38 AM, Chad Skinner <[email protected]>wrote:
> So, are the sessions replicated or do you lose active connections if a node > goes down? Yes. And your app goes down if the RDBMS goes down. > > I agree I don't have a problem with server session state ... the only > problem I have is we originally used JSF for a number of our applications > and I hate the reliance on POST in order to submit the serialized state. > There is no reason in my mind not to support GET and keep the session > information on the server .. For this LIFT seems a good fit. > > Not lift related, but does anyone know of an inexpensive load balancer that > works well and would support session affinity? The only reason I ask is that > I would like to replace our current software LB with a hardware device and > with the budget cuts due to the economy I need something that will work well > with relatively small loads and that is cost effective. > I would use Nginx software as a load balancer. It's fast enough to handle a ton of traffic (on the order of 10K requests per second on a dual opteron). > > -- Chad > > > On Wed, Mar 25, 2009 at 8:58 AM, Viktor Klang <[email protected]>wrote: > >> Hi Chad! >> >> Lift is intended to be clustered using a load-balancer with >> session-affinity, which means that no session replication is needed unless a >> node goes down. >> >> From only having almost a decade of web-framework development experience, >> I fully support the notion of having the session state serverside for highly >> interactive rich internet applications. >> Not only does it simplify development and enhance security, but it enables >> a whole lot of shortcuts not available for share-nothing approaches. >> >> That being said, I am a very big proponent for the REST model, which Lift >> is _very_ competent in providing an API for you to use, for ROA/REST needs. >> >> From what you may gather from this e-mail, I strongly believe in using the >> right tools for each job. >> >> Does this answer help you? >> >> Cheers, >> Viktor >> >> >> On Wed, Mar 25, 2009 at 2:46 PM, Chad Skinner <[email protected]>wrote: >> >>> >>>>> Not know much about lift yet and wanting to learn more, what is stored >>>>> in the server session for a simple application? I am assuming it is used >>>>> by >>>>> the binder to store the generated form field names so the submitted fields >>>>> can be rebound ... what other state does the framework store in it? >>>>> >>>> >>>> Any SessionVars are held in Session state. Bindings from HTML elements >>>> to functions are held in Session state. Bindings between Comet Actors and >>>> the HTML the represents them in held in Session state. >>>> >>>> >>> >>> Thanks for the information, I believe that the documentation states that >>> lift has its own session system and that it does not use the servers session >>> ... if this is true and you are running two redundant servers, will the >>> servers session replication / clustering copy the Lift session? >>> >>> State/session replication in a large cluster can cause problems, but for >>> our situation I don't see server state as being a problem as long as it is >>> minimal and replicates in clusters. >>> >>> I went to the Colorado Software Summit last year and went to a couple of >>> presentations by Yan Pujante and was very impressed by what they are doing >>> at linked-in. He presented a couple of sessions one on OSGi and the issues >>> they are solving or hoping to solve with it as well as the obstacles they >>> have encountered. Also, he did a presentation on their new security / >>> authentication system which was very interesting. One thing he mentioned was >>> that they were moving to a stateless environment, where the only state that >>> is maintained is that of the authenticated user object. >>> >>> Working for a school district I can say that Linked-in's world is ... >>> well different ... they have over 400 developers we have 2 ... they have I >>> believe he said 600 web servers ... we have two. Server state for us ... not >>> really a problem and I'd be happy if my development is easier, quicker and I >>> can better meet the needs of our users in a timely fashion. >>> >>> >>> >> >> >> -- >> Viktor Klang >> Senior Systems Analyst >> >> >> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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 -~----------~----~----~----~------~----~------~--~---
