Working With Spring Data JPA

SpringSource have recently released the first milestone of Spring Data JPA project. What are its features? and how can we use them. Spring framework already provides support to build a JPA based data access layer. So, what does Spring Data adds to it. I used it for one small application and found significant reduction of code. In this post we will use an Employee entity and EmployeeRepository as an example to work with Spring Data JPA.

We have a domain Employee :

@Entity
public class Employee {

  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  private Long id;

  private String name;

  // … methods omitted
}

We also have a EmployeeRepository handling the Employee entities. The interface and the implementation are given below.

package com.inphina.springdata.repository;

public interface EmployeeRepository {
	
	Employee save(Employee employee);
	
	List<Employee> findAll();
	
	Employee findById(Long id);
	
	List<Employee> findByName(String name, int page, int pageSize);

}

Configuring Spring Application Using Configuration Annotation

A Spring Module called Java Config has been there for some time now. With the release of Spring 3.0 SpringSource has pulled this module into the core Spring Framework as @Configuration.

How can we use this @Configuration in our application? and should we use it when we have XML and annotations for configuration already?

In Spring 2.5 we find that there is a support for Property Externalization. Which was good in several ways than before. What it meant was, that the properties file could be modified for different build environments by the administrator.

One good thing about this approach is that the administrator need not edit the application context file. Editing verbose XML has plenty of room for errors. Editing the properties file on the other hand is a whole lot simpler and is less error prone.

For example for configuring the datasource this is what we do typically. We used Property externalization in Spring 2.5 using PropertyPlaceHolderConfigurer.

<context:property-placeholder location="classpath:datasource.properties" />
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
		<property name="driverClassName"><value>${dataSource.driverClassName}</value></property>
		<property name="url"><value>${dataSource.url}</value></property>
		<property name="username"><value>${dataSource.username}</value></property>
		<property name="password"><value>${dataSource.password}</value></property>
</bean>

Mailing Google Docs As Attachment On Google App Engine

Our application works with Google Spreadsheet API to update spreadsheets. The application now needed to send mail with an attachment of a google spreadsheet. We posted our query on google docs community here and on Google app engine here and there were no clear directions of implementing it.

Let’s see how we went about implementing this feature.

Google provides its spreadsheet API and it allows you to create and retrieve data in Google Spreadsheets, but it does not allow us to either create or manage their permissions. Google also has Google Documents List API which can be used to create and retrieve a list of Google Spreadsheets. For our case Google Documents List API provides exporting functionality such that we can export Google documents in common formats like pdf, rtf, xls and others. Google also provides java mail api and with its Multi-Part Messages feature we can send attachment as well.

For implementing this, we used spreadsheet API to retrieve spreadsheet entry. Using the spreadsheet entry we used Google Documents List API to export it in the specified format and we used java mail api to send exported data as an attachment.

We used play framework for our implementation but it can also be applied on other java frameworks as well. The class EmailSender first creates a google spreadsheet service and document service.

public class EmailSender extends Controller {

private static final String META_FEED_URL = "https://spreadsheets.google.com/feeds/spreadsheets/private/full";
private static String spreadSheetName = "spreadsheetname";
private static String yourApplicationName = "emailSender-version1";
private static String userEmail = "yourmail@gmail.com";
private static String recepientEmail = "recepientmail@gmail.com";
private static String password = "password";


public static void emailSpreadsheetAsAttachment() throws AuthenticationException, MessagingException, IOException {
	SpreadsheetService spreadSheetService = createSpreadSheetService();
	DocsService documentService = createDocumentService();
	SpreadsheetEntry spreadsheetEntry = loadSpreadSheet(spreadSheetService, spreadSheetName);
	byte[] spreadSheetData = getSpreadSheetData(spreadSheetService, documentService, spreadsheetEntry);
	sendMailWithAttachment(spreadSheetData);
	}
. . .
. . .
private static SpreadsheetService createSpreadSheetService() throws AuthenticationException {
	SpreadsheetService spreadSheetService = new SpreadsheetService(yourApplicationName);
	spreadSheetService.setUserCredentials(userEmail, password);
	return spreadSheetService;
	}

private static DocsService createDocumentService() throws AuthenticationException {
	DocsService docsService = new DocsService(yourApplicationName);
	docsService.setUserCredentials(userEmail, password);
	return docsService;
       }
. . .
. . .
}

Managing Cold Start On Google App Engine

One of the major problem working on Google App engine is managing cold start. Well what is it?

Google App engine spins down the application when it is idle. On Google App engine, application does not get a permanent instance of java virtual machine. If there are no activities for a while then the JVM goes cold and application will have to start again to render a request. This is cold start and your application will be sluggish if you render a request to it after a while.

GAE team has accepted the issue and introduced “Ability to reserve instances to reduce application loading overhead” into their roadmap.

This is an issue we traditionally are not aware about while developing an application on Google App engine. If we are working on a greenfield project and we have a liberty of choosing the frameworks then we can stay away from heavy frameworks.

The application we are porting is Spring/Wicket/JPA tehnology stack and we like others were suffering from cold start. When the application warms up all the Spring beans are initialized again. Since we use JPA the EntityManagerFactory adds a significant amount of time for startup.

The quick fix for the cold start till Google App engine team figures it out, is to ping the application every few minutes. This will keep the application from going into the cold storage.

For this implementation to work we require a Servlet which essentially does nothing apart from receiving the request. We also require a cron job which renders request every few minutes. Let’s look at the servlet code listing and its mapping in web.xml.

public class PingServlet extends HttpServlet {

   private Logger logger = Logger.getLogger(PingServlet.class);

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
	logger.info("Keeping the application warm");
   }

   @Override
   protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
	doGet(req, resp);
   }
}

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.

Problems When Deploying Working Application on Google App Engine

Google Dev and production environment has differences. You may run into problems if you expect that application will also run fine on app engine if there are no errors on app engine development server. We are in process of porting an existing application on Google App engine. The application we are building uses Wicket, Spring and JPA. If you read the will it play in app engine you will find that Spring is compatible, Jpa works with datanucleus implementation and Wicket is semi compatible.

Most of the work required for porting the application required changes in data layer of the application. You can read more about the way to use jpa for persistence in Google App engine here. Wicket does work with the workarounds mentioned here. For wicket application we need to enable sessions in app engine config file.

<sessions-enabled>true</sessions-enabled>

Second we need to disable thread monitoring resource watcher.

@override
protected void init() {
	super.init();
	this.getResourceSettings().setResourcePollFrequency(null);
}

and at last we need to override the newSessionStore() to return HttpSession store because the default second level session store uses java.io.File which Google App Engine does not allow.

@override
protected void newSessionStore() {
	return new HttpSessionStore(this);
}

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.

Start Wicket project with maven

Wicket framework is the latest cousin in developing a web based project. Not much documentation is available in exploring it and only a few books are available to be read. It makes more sense to just delve in the code and what best to simply start a project with maven.

Start with executing the following in the command prompt:

user $ mvn archetype:generate

This will provide a host of projects you can start with, maven will ask for the number related to the kind of project you want to start with. You can select wicket-archetype-quickstart which is numbered at 37 for the latest maven.

It will then ask for defaults like artifactId and other values to generate the project structure. If we are using Eclipse IDE, we can generate the classpath by using the following in the command prompt:

user $ mvn eclipse:eclipse

Now import the maven project into eclipse to quick-start with the Wicket application.