When you bind a form, you write functions that handle parts of the form. They are stored in memory and when the form is submitted they are executed. They are triggered by assigning them a unique id and using it as the form element's name. There's no way to preserve the functions to survive a restart. So it may be a good idea to warn users in advance about maintenance and that form data won't be submitted if the page is loaded before and submitted after. It would be a nice feature if Lift could somehow detect query params that look like they are bound to functions but are not actually, and give the app a chance to notify the user that the form was not submitted, if such a thing is possible.
------------------------------------- John Pletka<[email protected]> wrote: The ProtoExtendedSession looks like it might match what I'm looking for. With that, they won't have to re-login, right? We're trying to avoid multi-page state-full workflows so that is not a problem. Are you saying if they have a form up, then submit it (say to update a record), that will fail? Will it generate an error that could be caught and nicely handled by the app? On a related note, any recommendations about a open-source loadbalancer that would allow you to take a server offline for new connections, but still allow the old connections to flow through? On Mon, Mar 1, 2010 at 5:39 PM, David Pollak <[email protected]>wrote: > > > On Mon, Mar 1, 2010 at 1:19 PM, Jeppe Nejsum Madsen <[email protected]>wrote: > >> Ahh just saw David beat me to it with the other reply :-) >> >> John Pletka <[email protected]> writes: >> >> > It is a business application - lots of forms, reports, data lookups. >> I'm >> > not too concerned about the performance on a single node - at any given >> time >> > we'll probably have a max of 1000 requests a minute coming in which I've >> > seen Lift handle easily. The biggest problem is we need near 100% >> up-time. >> >> But you can have near 100% uptime with sticky sessions. What you can't >> have is High Availability (HA), ie. users won't notice when a server >> breaks. >> > > There are 3 scenarios: > > 1. Unplanned fail-over. Having a hot standby and extended login > session (See ProtoExtendedSession). The user would lose a stateful > multi-page wizard and would lose input to the particular screen they were > on. It would appear as a "glitch"... not optimal, but not end of the > world. > 2. Planned transfer. You could shuffle all new sessions off to the new > machine and let the old sessions age on the old server. With a little > extra > work, you could demark when a user was done with a logic task (e.g., going > back to the home page) and use that as the trigger to move the session to > the new machine. > 3. Upgrade that breaks the DB schema. You're going to have downtime. > No way around it. > > > >> >> > That means having at least a second server in hot-standby mode >> > (preferably parallel production), and some way to do upgrades without >> > bringing the whole site offline. >> >> Doing rolling upgrades is never easy, even if you don't share state. You >> may have all this figured, but you need to account for different app >> versions running simultaneously, expanding/shrinking db upgrades etc. >> >> /Jeppe >> >> -- >> 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]<liftweb%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > 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]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > -- 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. -- 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.
