Toby, Thanks for clarifying the problem. the way my application is written, that scenario would never occur.
On Sep 24, 1:40 pm, Toby Reyelts <[email protected]> wrote: > On Thu, Sep 24, 2009 at 12:48 PM, Jay Damon <[email protected]> wrote: > > > Toby, > > > Thanks for your response. > > > 1) I had enabled sessions for my project, when I first installed the > > eclipse (3.4) plugin a few months ago. > > 2) As a developer, I always ensure I implement Serializable. > > > Re: 3) This is the one that concerns me. I don't care if I get the > > same HttpSession object but does this mean I may possibly lose the > > references to the data maintained in the session object? If so, is > > this the problem the gaeutilities session class implementation is > > designed to correct? > > Again, I don't know anything about gaeutilities. It is not Google written or > supported software. > > Or does it just ensure the SAME session object > > > is returned? > > > I would appreciate more clarification on 3). Thanks! > > It means that a single user using a single http session can have multiple > http requests accessing that session. Currently, the entire session state is > written to the datastore and memcache at the end of an http request if we > detect that the session has been modified. Here's an example scenario in > which you could see problems: > > Time Request 1 Request 2 > ---- --------- --------- > 1 read_session read_session - session states in request 1 and 2 > are identical copies > 2 put(new_key) put(different_key) - session state copies mutated > 3 store_session - request 1's state distributed to > memcache + datastore > 4 store_session - request 2's state overwrites > changes from request 1 > > > > > On Sep 24, 11:46 am, Toby Reyelts <[email protected]> wrote: > > > Jay, > > > > In general, no there are not limitations on App Engine's HttpSession. > > Here > > > are some things that are useful to know, though: > > > > 1) They aren't enabled by default. You need to turn them > > > on< > >http://code.google.com/appengine/docs/java/config/appconfig.html#Enab.. > > .>in > > > appengine-web.xml. > > > 2) They are distributed and persistent. This means that the objects you > > > stick in them need to be Serializable. This is no different from any > > other > > > container that supports clustered or persistent HttpSessions. There is an > > > outstanding issue that our dev_appserver doesn't require HttpSession > > values > > > to be Serializable like prod. > > > 3) App Engine does not serialize requests to the same HttpSession. That > > > behavior is a deviation from the standard. > > > > On Thu, Sep 24, 2009 at 8:55 AM, Jay Damon <[email protected]> wrote: > > > > > I am relatively new to App Engine. Recently I have starting seeing > > > > indications that there are limitations? on the the use of HTTP > > > > sessions in App Engine? For example, I see that there is a > > > > gaeutilities project that provides a class Session: An http session > > > > class to preserve identity across http requests. Are there > > > > limitations on HTTP sessions in App Engine? If so, what are those > > > > limitations? If not, what specific issues does the gaeutilities > > > > project class address? Many of the limitations in App Engine concern > > > > me but any limitations at all on HTTP sessions would be a showstopper > > > > for me.- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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/google-appengine-java?hl=en -~----------~----~----~----~------~----~------~--~---
