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 -
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to