BeJUG talk, Google App Engine, Paul Bakker

My notes for another interesting BeJUG talk, on 9 June 2009, in Leuven.

Introduction to developing applications for Google App Engine


IAAS: vitual hardware platform, need to install OS, java, application server, application,… No limitations, no locking BUT you have to manage it all yourself and no automatic scaling. Example is Amazon Elastic Cloud.
PAAS: virtual application server, no control over OS, run in sandbox. No server management, easy deployment, autmatic scaling BUT limited by the sandbox, can’t run existing apps as-is. Example is GAE.
SAAS: run an application in the cloud.


Sandbox + servlet container + application
with admin console and eveloper tools
bigtable (with JPA/JDO if you want)
services : memcache, URL fetch, mail, XMPP, Images, Google Accounts, Task Queues

You get a (free) subdomain
You can add your own domain name
Each request has a 30s timeout
Streaming responses are not allowed

JVM’s are started on demand, on app startup, after inactivity or when upscaling
Starting a JVM causes a “loading request”, the app is loaded during that request

Sandbox, you can’t
– write to the filesystem
– open sockets
– create threads
– invoke most System calls
– reflect on classes not belonging to the app
– use JRE classes not on the whitelist

Supported: JDO, JPA, JSF, JSP, Servlet 2.4, JAXB, XML apis, JAX-RS,…

GAE includes a staging environment (though accessing the same data store, so have to be careful)

Storing data

BigTable: distributed, highly scalable, not relational, schema-less, properties have one or more values

Kind => table
Key => primary key
Entity group => partition (usually on the same shard)
typed properties => columns

Entities are hierarchical, useful for “owned” relationships (eg a chapter can’t exist without a book)

Queries (JPQL)
Supports some filters >,>=,…
Each query uses an index
An index is combination of kind, properties, sort order etc

– data store is transactional
– all writes are atomic
– only one entity group can be used in a transaction (as they can be on different physical servers)
within a transaction: serializable isolation
outside: get is read committed
queries are more subtle, commit is two milestones, (1) out in datastore, making entity visible, (2) update indexes

there is a low level JDBC like API, using GQL queries

JPA: add JPA and DataNucleaus jars, create persistence.xml, configure post-compilation class enhancement
JPA limitations: no joined inheritance, no single table inheritance (for now), no many-to-many relationships, no unowned one-to-many relationships, no join/aggregation/polymorphic queries

Constraining pages (security constraint in web.xml)
– Uses Google Accounts
– Require users to log-in
– Require the admin role (==developer on GAE) (only existing specific role)

– receiving mails is also possible (
– AppEngine will post this to a servlet /_ah/mail/address (page which is not accessible from outside)

Cron jobs
– tasks run on certain intervals (again a servlet is called on a specific URL, so 30s time limit)
– configure in WEB-INF/cron.xml

Task queues, can be used to split tasks in small chunks
– asynchronous, parallel background tasks
– modeled as web hooks (with data+code) (30s limit)
– custom queues can be created, can be throttled (rate) and can have a bucket size

Blobstore service to save files
– max 2GB
– upload by form POST, returns a blob key
– serve file using blob key

– distributed in-memory cache, cross JVM instances
– JCache API (JSR-107)
– low level API

Easy out-of-container testing. Most services have in-memory versions.

One Comment

  1. Paul Bakker says:

    Funny, I was searching for information about a specific GAE problem and I end up looking at notes about my own talk 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen