GAE Problems: Slim3 To The Rescue?

For the past few months we have been working on porting a time-sheet application on Google App Engine. The application we were trying to port had Spring for Dependency Injection, Hibernate for persistence and Wicket as the web framework. Looking at the will it play in app engine Hibernate was an easy call, it is not compatible on Google App Engine, wicket works with some workaround and Spring is fully supported. We decided to go with JPA as it is easier to convert a hibernate application to JPA than to other ORM framework. We decided to continue with Spring and Wicket.

We encountered several problems during porting the application. Most of the effort went in increasing the performance. We used Key-Only-Query, memcache to increase performance. We also had issues with handling consistency of datastore operations across entity groups.

When we select framework for application development, we think in terms of the application performance and the ease of application development. When we are not porting an application but doing a new development we can choose frameworks more freely. For new application development on Google App Engine Slim3 framework seems like a good option.

Google App Engine has a notion of entity groups. It is a very important concept and decides how the Entities will be mapped in JPA for the application.

There is a limitation that an Entity cannot have more than one parent. This can be a major issue while re-defining Entity associations for Google App Engine for the application. The Entity Groups also decide the transaction strategy for an application. Simply put you can only apply transaction on a single Entity Group. Is there a platform which allow us to provide transactions across Entity groups. Slim3 does allow us to work across entity groups.

Slim3 example for transferring amount across two accounts:

Implementing Multi-tenancy On Google App Engine

Google recently added support for multi-tenancy for applications via the Namespaces API. We are in process of porting an application to Google App engine. We were thinking of making our application multi-tenant. With the new Namespaces API in our arsenal we decided to give it a try. To our surprise implementing multi-tenancy is easy, we were done with it in couple of hours!

With multi-tenancy, multiple client organizations (or “tenants”) can all run on a same hosted application. In effect due to segregation of data using a unique namespace for each client. This allows us to serve the same application to different customers, with each customer seeing their own unique copy of the application.

Let’s see how we went about implementing it. First of all we needed a Filter it sets unique name-space for each request. Here is the code listing.

Improve Performance By Using Keys Only Query on Google App Engine

It has been around two months since we started to port an existing application on Google App engine. It used Hibernate for persistence, Wicket framework for web layer and Spring as an Ioc container. Looking at the will it play on appengine we had to change Hibernate to use either JPA or JDO. We decided on JPA purely on the basis of experience we had on JPA compared to JDO. Wicket is semi compatible and we made it work by the three standard workarounds described here.

Changing the persistence layer from Hibernate to JPA was the most challenging task. Not only we had to break the relationships between entities because of the Datastore’s notion of entity groups but also due to several performance optimizations we had to do later. We will have a look at how can we use keys-only query in JPA to increase performance.

We had trouble mapping the associations in JPA for Google App engine for which we blogged about the case for unowned keys and managing multiple parent problem. Understanding of Entity Groups and transactions are extremely important for implementing persistence on Google App Engine. This becomes especially important for porting an application to Google App engine.

In our application there were certain parts we could find were expensive either in terms of CPU usage or in Datastore calls. We were able to optimize application performance using keys-only queries.

Generating Excel Files On Google App Engine For A Wicket Application

We are porting an existing Wicket application on Google App Engine. This application uses Wicket, Spring and Hibernate. If you read will it play in app engine, you will notice that Wicket is semi compatible and it does work with workarounds. Hibernate on the other hand is incompatible and Spring is fully supported. We began porting this application after changing persistence to use JPA instead of hibernate. We used workarounds for wicket described here.

This application generates Excel sheets and used Apache POI for generating Excel reports. Apache POI is not supported in Google App engine and it seems that Apache POI will not change their implementation to make it work for Google App Engine in near future.

We started looking at ways to generate Excel sheets. We decided on using java Excel API for our application. Let’s see how can we generate excel files for a Wicket application on Google App engine.

First of all add the maven dependency for JExcel in the application:

<dependency>
    <groupId>net.sourceforge.jexcelapi</groupId>
    <artifactId>jxl</artifactId>
    <version>2.6.10</version>
</dependency>

Generating Charts In Wicket Application On Google App Engine

We are in process of porting an existing Wicket application on Google App engine. This application’s charting engine used Java color classes along with Swing components to generate dynamic images. These images are then used by Wicket to display on the front-end . Unfortunately Google app engine does not support these classes. We therefore had to find an alternative to generate Charts for our application.

We decided upon using google charts in our Wicket based project. We came across this wicket google charts sub project which has the capabilities to generate charts for the application. We found out later that it used awt classes at some parts to generate charts. Looking at the code from this project we realized that it is simple to do this on our own.

Google charts require an URL format which has data along with meta information on how to display it. This well formed URL is embedded in the image tag of the rendered html content is enough to display the chart on the browser. So, in order to generate charts we had to crunch the data in the application to generate a well formed URL. Then we simply had to embed this URL in the image tag to render it on the browser. For example an URL like this:

http://chart.apis.google.com/chart?chs=350x200&chd=s:WORL&cht=bhs&chxt=x,y&chxl=0:|0|5|10|15|20|25|30|35|1:|IBM|GE|TCS|SA

will generate an image like this:

Managing Multiple Parent Persistence Problem in App Engine

We are in process of porting an entire application on google app engine. This application has persistence using JPA and as usual contains mapping between entities using annotations. The mapping like @OnetoMany and @ManytoOne in Jpa may throw lot of errors in google app engine and therefore is neither straightforward nor trivial. In this blog we will see where our mapping may fail, with specific problem related to multiple parent key provider fields. Google app engine may throw this error in our application, we will see how can we manage it with unowned relationships in our application.

We have three entities User, Project and ProjectAssignment. ProjectAssignment entity has @ManyToOne mapping with an User and a Project. In these relationships we also have a bidirectional mapping using @OneToMany relationship from User and Project for ProjectAssignment.

Remote Debugging Google App Engine Application on Eclipse

Sometimes it is handy to debug our application source code even when it is executing outside our IDE. This blog will explain how can we remotely debug a web application project developed in Google App Engine on eclipse IDE.

The linux command to start web application on Google App engine development application server is

dev_appserver.sh <exploded WAR directory path>

The command runs the application on embedded Jetty server. The problem then reduces to do remote debugging of application with eclipse. We only have to open a debug port on jetty to connect to.

Edit the dev_appserver.sh file to this

#!/bin/bash
# Launches the development AppServer
[ -z "${DEBUG}" ] || set -x  # trace if $DEBUG env. var. is non-zero
SDK_BIN=`dirname $0 | sed -e "s#^\\([^/]\\)#${PWD}/\\1#"` # sed makes absolute
SDK_LIB=$SDK_BIN/../lib
SDK_CONFIG=$SDK_BIN/../config/sdk
java -ea -cp "$SDK_LIB/appengine-tools-api.jar" \
com.google.appengine.tools.KickStart
--jvm_flag=-Xdebug
--jvm_flag=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044\
com.google.appengine.tools.development.DevAppServerMain $*

This will open a listening port on 1044 which eclipse can connect to using remote debugging. Let us look at how can we configure eclipse IDE to remotely debug our application. In your Eclipse IDE