[Lift] Re: Session usage in Lift
Actually, I'm checking in code right now that allows you to have a custom session dispatcher. You can vend a single session for use by all HTTP requests, if you want (see LiftRules.getLiftSession). This allows you to pretty much ignore the session related stuff in Lift. No JSESSIONID, etc. But if you load-balance across many machines, you'll lose all of the Lift Comet, Ajax, and secure form support. On Wed, May 27, 2009 at 2:35 AM, Kristinn wrote: > > ok, thanks for the info, I myself have not used such frameworks, but > I'm always willing to try something new and I only hear good things > about Lift. > > So, we must switch to sticky load balancing (or do some kind of > session replication) in order to use Lift, cool thanks guys. > > On May 27, 11:05 am, "marius d." wrote: > > On May 27, 9:17 am, Kristinn wrote: > > > > > Yes, I understand your confusion, however sometimes people make > > > designs that don't make much sense to others on first look (like > > > "using sessions for rendering all html"). But there are often good > > > reasons for these decisions (admittedly often these decisions are just > > > bad). > > > > > In our case we only need the user id for each request, we wouldn't > > > have needed to store anything else in the session. So if we use cookie > > > to do the authentication, we don't need session replication nor sticky > > > loadbalancing. Therefore we have very efficient load balancing, fail- > > > over, and zero-downtime-deployments. You can take out any instance at > > > anytime without the user noticing a thing. Sorry, this sounds like I'm > > > trying to defend the design, I wasn't going to do that. > > > > > btw. Why is the session used for rendering the html? > > > > Lift (like so many other frameworks) request processing & rendering > > phase happens in a stateful context meaning that it allows you out of > > the box to maintain state between requests. In this way you can > > seamlessly add COMET support a many other features without worrying > > about state etc. Also for Lift the users bound functions must be kept > > per session in order to work. So rendering markup is not as simple as > > it may appear as lots of things are correlated to that. if you have a > > completely static markup (plain HTML) then this markup should probably > > be served by a front-end static content. > > > > > > > > > > > > > On May 26, 10:44 pm, David Pollak > > > wrote: > > > > > > On Tue, May 26, 2009 at 1:26 PM, Kristinn < > kristinn.daniels...@gmail.com>wrote: > > > > > > > Thanks for your answer. > > > > > > > I'm not sure what you'd like to know about the app. > > > > > It's an internal project, task and idea management application, > > > > > written in Java using the Stripes web framework, and Apache Lucene > for > > > > > persistence. > > > > > > > We use a cookie to authenticate the user, this is done on each > > > > > request. > > > > > > So do you have content and access control that is specific to each > use, but > > > > you're just not using the Servlet container's session mechanism? > > > > > > Sorry for being confused. > > > > > > > Is there anything in particular that you would like to know? > > > > > > > On May 26, 10:00 pm, David Pollak > > > > > wrote: > > > > > > At this point, Lift requires sessions for all HTML rendering. It > might > > > > > be > > > > > > possible to do something such that all the various requests share > the > > > > > same > > > > > > session and there's no JSESSIONID and no need for stickiness. > > > > > > > > Can you tell us a little more about your app? > > > > > > > > On Tue, May 26, 2009 at 12:07 PM, Kristinn < > > > > > kristinn.daniels...@gmail.com>wrote: > > > > > > > > > Hi, I'm looking into migrating an existing application to Lift. > This > > > > > > > application does not use sessions at all, and we do load > balancing > > > > > > > without session stickiness. Now my question is: does Lift for > some > > > > > > > reason require sessions on it's own? Or, would we have to > switch to > > > > > > > load balancing with session stickiness? > > > > > > > > > Thanks, > > > > > > > Kristinn > > > > > > > > -- > > > > > > 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 > > > > > > -- > > > > 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 > > > > -- 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 liftweb@go
[Lift] Re: Session usage in Lift
ok, thanks for the info, I myself have not used such frameworks, but I'm always willing to try something new and I only hear good things about Lift. So, we must switch to sticky load balancing (or do some kind of session replication) in order to use Lift, cool thanks guys. On May 27, 11:05 am, "marius d." wrote: > On May 27, 9:17 am, Kristinn wrote: > > > Yes, I understand your confusion, however sometimes people make > > designs that don't make much sense to others on first look (like > > "using sessions for rendering all html"). But there are often good > > reasons for these decisions (admittedly often these decisions are just > > bad). > > > In our case we only need the user id for each request, we wouldn't > > have needed to store anything else in the session. So if we use cookie > > to do the authentication, we don't need session replication nor sticky > > loadbalancing. Therefore we have very efficient load balancing, fail- > > over, and zero-downtime-deployments. You can take out any instance at > > anytime without the user noticing a thing. Sorry, this sounds like I'm > > trying to defend the design, I wasn't going to do that. > > > btw. Why is the session used for rendering the html? > > Lift (like so many other frameworks) request processing & rendering > phase happens in a stateful context meaning that it allows you out of > the box to maintain state between requests. In this way you can > seamlessly add COMET support a many other features without worrying > about state etc. Also for Lift the users bound functions must be kept > per session in order to work. So rendering markup is not as simple as > it may appear as lots of things are correlated to that. if you have a > completely static markup (plain HTML) then this markup should probably > be served by a front-end static content. > > > > > > > On May 26, 10:44 pm, David Pollak > > wrote: > > > > On Tue, May 26, 2009 at 1:26 PM, Kristinn > > > wrote: > > > > > Thanks for your answer. > > > > > I'm not sure what you'd like to know about the app. > > > > It's an internal project, task and idea management application, > > > > written in Java using the Stripes web framework, and Apache Lucene for > > > > persistence. > > > > > We use a cookie to authenticate the user, this is done on each > > > > request. > > > > So do you have content and access control that is specific to each use, > > > but > > > you're just not using the Servlet container's session mechanism? > > > > Sorry for being confused. > > > > > Is there anything in particular that you would like to know? > > > > > On May 26, 10:00 pm, David Pollak > > > > wrote: > > > > > At this point, Lift requires sessions for all HTML rendering. It > > > > > might > > > > be > > > > > possible to do something such that all the various requests share the > > > > same > > > > > session and there's no JSESSIONID and no need for stickiness. > > > > > > Can you tell us a little more about your app? > > > > > > On Tue, May 26, 2009 at 12:07 PM, Kristinn < > > > > kristinn.daniels...@gmail.com>wrote: > > > > > > > Hi, I'm looking into migrating an existing application to Lift. This > > > > > > application does not use sessions at all, and we do load balancing > > > > > > without session stickiness. Now my question is: does Lift for some > > > > > > reason require sessions on it's own? Or, would we have to switch to > > > > > > load balancing with session stickiness? > > > > > > > Thanks, > > > > > > Kristinn > > > > > > -- > > > > > 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 > > > > -- > > > 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Session usage in Lift
If you were building an application which didn't require any COMET nor needed any data stored in the session and you were happy to disable the random form field name generation (so a form submission, due to failover/load balancing could be processed by any servlet container in the cluster) - would Lift still work in failover scenarios or would it totally barf? I understand that generating random names for things can be troublesome (I can imagine the callbacks used in forms having similar problems) - are there other bits of Lift that could cause issues? I'm just wondering if Lift can ever be used in a share-nothing kinda deployment, or if session replication is mandatory. 2009/5/27 marius d. : > > > On May 27, 9:17 am, Kristinn wrote: >> Yes, I understand your confusion, however sometimes people make >> designs that don't make much sense to others on first look (like >> "using sessions for rendering all html"). But there are often good >> reasons for these decisions (admittedly often these decisions are just >> bad). >> >> In our case we only need the user id for each request, we wouldn't >> have needed to store anything else in the session. So if we use cookie >> to do the authentication, we don't need session replication nor sticky >> loadbalancing. Therefore we have very efficient load balancing, fail- >> over, and zero-downtime-deployments. You can take out any instance at >> anytime without the user noticing a thing. Sorry, this sounds like I'm >> trying to defend the design, I wasn't going to do that. >> >> btw. Why is the session used for rendering the html? > > Lift (like so many other frameworks) request processing & rendering > phase happens in a stateful context meaning that it allows you out of > the box to maintain state between requests. In this way you can > seamlessly add COMET support a many other features without worrying > about state etc. Also for Lift the users bound functions must be kept > per session in order to work. So rendering markup is not as simple as > it may appear as lots of things are correlated to that. if you have a > completely static markup (plain HTML) then this markup should probably > be served by a front-end static content. > > > >> >> On May 26, 10:44 pm, David Pollak >> wrote: >> >> > On Tue, May 26, 2009 at 1:26 PM, Kristinn >> > wrote: >> >> > > Thanks for your answer. >> >> > > I'm not sure what you'd like to know about the app. >> > > It's an internal project, task and idea management application, >> > > written in Java using the Stripes web framework, and Apache Lucene for >> > > persistence. >> >> > > We use a cookie to authenticate the user, this is done on each >> > > request. >> >> > So do you have content and access control that is specific to each use, but >> > you're just not using the Servlet container's session mechanism? >> >> > Sorry for being confused. >> >> > > Is there anything in particular that you would like to know? >> >> > > On May 26, 10:00 pm, David Pollak >> > > wrote: >> > > > At this point, Lift requires sessions for all HTML rendering. It might >> > > be >> > > > possible to do something such that all the various requests share the >> > > same >> > > > session and there's no JSESSIONID and no need for stickiness. >> >> > > > Can you tell us a little more about your app? >> >> > > > On Tue, May 26, 2009 at 12:07 PM, Kristinn < >> > > kristinn.daniels...@gmail.com>wrote: >> >> > > > > Hi, I'm looking into migrating an existing application to Lift. This >> > > > > application does not use sessions at all, and we do load balancing >> > > > > without session stickiness. Now my question is: does Lift for some >> > > > > reason require sessions on it's own? Or, would we have to switch to >> > > > > load balancing with session stickiness? >> >> > > > > Thanks, >> > > > > Kristinn >> >> > > > -- >> > > > 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 >> >> > -- >> > 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 > > > -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Session usage in Lift
On May 27, 9:17 am, Kristinn wrote: > Yes, I understand your confusion, however sometimes people make > designs that don't make much sense to others on first look (like > "using sessions for rendering all html"). But there are often good > reasons for these decisions (admittedly often these decisions are just > bad). > > In our case we only need the user id for each request, we wouldn't > have needed to store anything else in the session. So if we use cookie > to do the authentication, we don't need session replication nor sticky > loadbalancing. Therefore we have very efficient load balancing, fail- > over, and zero-downtime-deployments. You can take out any instance at > anytime without the user noticing a thing. Sorry, this sounds like I'm > trying to defend the design, I wasn't going to do that. > > btw. Why is the session used for rendering the html? Lift (like so many other frameworks) request processing & rendering phase happens in a stateful context meaning that it allows you out of the box to maintain state between requests. In this way you can seamlessly add COMET support a many other features without worrying about state etc. Also for Lift the users bound functions must be kept per session in order to work. So rendering markup is not as simple as it may appear as lots of things are correlated to that. if you have a completely static markup (plain HTML) then this markup should probably be served by a front-end static content. > > On May 26, 10:44 pm, David Pollak > wrote: > > > On Tue, May 26, 2009 at 1:26 PM, Kristinn > > wrote: > > > > Thanks for your answer. > > > > I'm not sure what you'd like to know about the app. > > > It's an internal project, task and idea management application, > > > written in Java using the Stripes web framework, and Apache Lucene for > > > persistence. > > > > We use a cookie to authenticate the user, this is done on each > > > request. > > > So do you have content and access control that is specific to each use, but > > you're just not using the Servlet container's session mechanism? > > > Sorry for being confused. > > > > Is there anything in particular that you would like to know? > > > > On May 26, 10:00 pm, David Pollak > > > wrote: > > > > At this point, Lift requires sessions for all HTML rendering. It might > > > be > > > > possible to do something such that all the various requests share the > > > same > > > > session and there's no JSESSIONID and no need for stickiness. > > > > > Can you tell us a little more about your app? > > > > > On Tue, May 26, 2009 at 12:07 PM, Kristinn < > > > kristinn.daniels...@gmail.com>wrote: > > > > > > Hi, I'm looking into migrating an existing application to Lift. This > > > > > application does not use sessions at all, and we do load balancing > > > > > without session stickiness. Now my question is: does Lift for some > > > > > reason require sessions on it's own? Or, would we have to switch to > > > > > load balancing with session stickiness? > > > > > > Thanks, > > > > > Kristinn > > > > > -- > > > > 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 > > > -- > > 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Session usage in Lift
Yes, I understand your confusion, however sometimes people make designs that don't make much sense to others on first look (like "using sessions for rendering all html"). But there are often good reasons for these decisions (admittedly often these decisions are just bad). In our case we only need the user id for each request, we wouldn't have needed to store anything else in the session. So if we use cookie to do the authentication, we don't need session replication nor sticky loadbalancing. Therefore we have very efficient load balancing, fail- over, and zero-downtime-deployments. You can take out any instance at anytime without the user noticing a thing. Sorry, this sounds like I'm trying to defend the design, I wasn't going to do that. btw. Why is the session used for rendering the html? On May 26, 10:44 pm, David Pollak wrote: > On Tue, May 26, 2009 at 1:26 PM, Kristinn > wrote: > > > > > Thanks for your answer. > > > I'm not sure what you'd like to know about the app. > > It's an internal project, task and idea management application, > > written in Java using the Stripes web framework, and Apache Lucene for > > persistence. > > > We use a cookie to authenticate the user, this is done on each > > request. > > So do you have content and access control that is specific to each use, but > you're just not using the Servlet container's session mechanism? > > Sorry for being confused. > > > > > > > > > Is there anything in particular that you would like to know? > > > On May 26, 10:00 pm, David Pollak > > wrote: > > > At this point, Lift requires sessions for all HTML rendering. It might > > be > > > possible to do something such that all the various requests share the > > same > > > session and there's no JSESSIONID and no need for stickiness. > > > > Can you tell us a little more about your app? > > > > On Tue, May 26, 2009 at 12:07 PM, Kristinn < > > kristinn.daniels...@gmail.com>wrote: > > > > > Hi, I'm looking into migrating an existing application to Lift. This > > > > application does not use sessions at all, and we do load balancing > > > > without session stickiness. Now my question is: does Lift for some > > > > reason require sessions on it's own? Or, would we have to switch to > > > > load balancing with session stickiness? > > > > > Thanks, > > > > Kristinn > > > > -- > > > 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 > > -- > 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Session usage in Lift
On Tue, May 26, 2009 at 1:26 PM, Kristinn wrote: > > Thanks for your answer. > > I'm not sure what you'd like to know about the app. > It's an internal project, task and idea management application, > written in Java using the Stripes web framework, and Apache Lucene for > persistence. > > We use a cookie to authenticate the user, this is done on each > request. So do you have content and access control that is specific to each use, but you're just not using the Servlet container's session mechanism? Sorry for being confused. > > > Is there anything in particular that you would like to know? > > On May 26, 10:00 pm, David Pollak > wrote: > > At this point, Lift requires sessions for all HTML rendering. It might > be > > possible to do something such that all the various requests share the > same > > session and there's no JSESSIONID and no need for stickiness. > > > > Can you tell us a little more about your app? > > > > On Tue, May 26, 2009 at 12:07 PM, Kristinn < > kristinn.daniels...@gmail.com>wrote: > > > > > > > > > Hi, I'm looking into migrating an existing application to Lift. This > > > application does not use sessions at all, and we do load balancing > > > without session stickiness. Now my question is: does Lift for some > > > reason require sessions on it's own? Or, would we have to switch to > > > load balancing with session stickiness? > > > > > Thanks, > > > Kristinn > > > > -- > > 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 > > > > -- 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Session usage in Lift
Thanks for your answer. I'm not sure what you'd like to know about the app. It's an internal project, task and idea management application, written in Java using the Stripes web framework, and Apache Lucene for persistence. We use a cookie to authenticate the user, this is done on each request. Is there anything in particular that you would like to know? On May 26, 10:00 pm, David Pollak wrote: > At this point, Lift requires sessions for all HTML rendering. It might be > possible to do something such that all the various requests share the same > session and there's no JSESSIONID and no need for stickiness. > > Can you tell us a little more about your app? > > On Tue, May 26, 2009 at 12:07 PM, Kristinn > wrote: > > > > > Hi, I'm looking into migrating an existing application to Lift. This > > application does not use sessions at all, and we do load balancing > > without session stickiness. Now my question is: does Lift for some > > reason require sessions on it's own? Or, would we have to switch to > > load balancing with session stickiness? > > > Thanks, > > Kristinn > > -- > 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Session usage in Lift
At this point, Lift requires sessions for all HTML rendering. It might be possible to do something such that all the various requests share the same session and there's no JSESSIONID and no need for stickiness. Can you tell us a little more about your app? On Tue, May 26, 2009 at 12:07 PM, Kristinn wrote: > > Hi, I'm looking into migrating an existing application to Lift. This > application does not use sessions at all, and we do load balancing > without session stickiness. Now my question is: does Lift for some > reason require sessions on it's own? Or, would we have to switch to > load balancing with session stickiness? > > Thanks, > Kristinn > > > > -- 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
