When a J2EE developer starts the design of a Google App Engine application he has to face some problems and adapts some of the well-established design patterns in web application development. Let's start with a bit of introduction to explain what is a Google App Engine application.
What is Google App Engine
Citing the corresponding google page: "Google App Engine lets you run your web applications on Google's infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it's ready to serve your users."
Basically Google App Engine is a service that lets you put your application "in the cloud", a cloud completely managed by Google, so you don't have to worry about the scalability or reliability of your application. Every request made to a page of your application will be managed by one of the server in this infrastructure, but no one can guarantee that the next request will be assigned to that machine as well.
How the http session is managed
Session handling must be explicitly enabled by adding to your app engine configuration filethis.getThreadLocalRequest().getSession();
When you enable it, you will find serialized sessions among your datastore entities as _ah_SESSION, this is due to the fact that "the cloud" will read and write sessions from and to the datastore, and not from and to memory as the J2EE specification states (excluding an application deployed on a cluster).
Every time the HttpSession setAttribute method is invoked, the related datastore entity is updated and every subsequent invocation to the related getAttribute method will return the same object, as you would expect from a standard web application. The problem is when your services manipulate objects stored in the session, in that case your changes will be lost when another service will get the object from the session. A very simple sample:
Service A
Person p = new Person();
p.setName("Jack");
session.setAttribute("person", p);
Service B
Person p = (Person) session.getAttribute("person");
System.out.println(p.getName()); // prints "Jack"
p.setName("Andy");
Service A again
Person p = (Person) session.getAttribute("person");
System.out.println(p.getName()); // prints "Jack" in GAE,
// prints "Andy" in a standard J2EE evironment
If you want a consistent behaviour you need to invoke setAttribute again after having modified the Person object in the session. This workaround will solve all the inconsistencies but has a pretty important trade-off, every setAttribute will trigger a new serialization and write to the datastore; ok, you are in the Google cloud, but the free resources are limited.
Alternatives to the http session
There are a lot of alternative implementantion of session utilities if you use Python: http://wiki.github.com/dound/gae-sessions/ (it also has a comparison table with other libraries). For Java developers the only alternative is to use the Memcache service and/or the DataStore service. While the former has the problem of the data expiration strategy: http://code.google.com/appengine/docs/java/memcache/overview.html#How_Cached_Data_Expires, the latter will suffer of the same performance problems of the GAE session implementation.