Camac IT Ltd

Sharing persistent data between two apps deployed to GAE (Google AppEngine platform) is possible, although not obvious.

Why would you want to do this?

For anything but the most trivial application you’ll likely have the application partitioned into different silos.  For example, I’m developing an application which has a Webservices API, a GWT-based (GUI) interface for the user and a separate GWT-based interface for the administrator.  All three share a common POJO data model (and underlying data) and some business logic but thats about all.  For security, scalability, safety and reliability reasons I wanted all three silos packaged into separate packages (war files) yet still have each independently deployed silo be able to share data with the others.  In other words, they need to share a GAE datasource between them.  But if the silos are deployed to their own applicationID in GAE then they are each assigned their own datasource and they won’t be able to share data.

How is it done?

The trick to allowing separate packages to share the same datasource is to deploy the different packages (wars) under the same applicationID and to assign each package its own version to avoid each deployment overwriting other deployments.  Fortunately in GAE, version labels are not just numeric they can be alphanumeric and thus mnemonics can be assigned that reflect what the ‘version’ corresponds to. For example you could choose applicationID=’myapp’ (which maps to http://myapp.appspot.com) and then for the webservices silo use version=’webservices’ and for the client GUI part use version=’client’.  This would result in the following URL namespace for your app:

http://webservices.myapp.appspot.com for the webservices package, and

http://client.myapp.appspot.com for the client GUI package.

Since all the deployed bundles (wars) share the same applicationID they can all access the same datasource and can thus share persistent data.  And since each deployment bundle has its own version, each can be addressed independently and directly via http.

Just remember that the datastore is much more lenient when it comes to data schemas so you’ll need to ensure that access to the persistent shared datastore is done through the same set of POJOs across each silo in order to preserve the data’s consistency (schema level).  The best way to implement that is to have a common datamodel package that each silo uses.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.