Persisting an Array with OpenJPA

One of the key features of JPA is the ability to add metadata annotations to a POJO such that it can be used interchangably in a persistence enabled and/or non-persistent environment.  The JPA 1.0 specification provides persistence metadata for most of the common data structures and object/entity relationships.  The specification clearly defines that collection-valued persistent fields and properties must be defined as one of: java.util.Collection, java.util.Set, java.util.List, or java.util.Map.  Notice there is no mention of the standard array type (ex.  MyObjectArray[]).  That means if your POJO contains a field that is an array you'll typically need to wrapper that array with one of the collection classes above, tag it as a relationship (most likely a OneToMany) and expose that collection type as a persistent property or change to use one of the supported collection classes.  While wrappering a collection is fairly simple; a) it is a logic change (vs. adding metadata) which may undesirable and b) it can have performance impacts due to copying references from one structure to another. 

If you are like me and that doesn't sit well with you, OpenJPA provides a extension, @org.apache.openjpa.persistence.PersistentCollection which can be used to persist an array.  OpenJPA does this by using a separate "container table" to store array elements.  If maintaining the order of the array is also important (which is typically the case), OpenJPA provides the @org.apache.openjpa.persistence.jdbc.OrderColumn extension.  OrderColumn specifies the column in the container table which will be used to store the index of the array entries.  If you don't like the default container table you can also customize that using the @org.apache.openjpa.persistence.jdbc.ContainerTable extension.

Here's a bit of incomplete code which uses PersistentCollection and OrderColumn to persist a deck of cards stored as an array.  Also, note that PersistentCollection supports cascade and fetch configuration, similar to the JPA relationship annotations.

import org.apache.openjpa.persistence.PersistentCollection;

import org.apache.openjpa.persistence.jdbc.OrderColumn;

@Entity

public class Deck {

    @PersistentCollection(elementCascade=CascadeType.PERSIST,

            fetch=FetchType.EAGER)

    @OrderColumn(name="cardorder")

    private Card[] cards;

// ...

}

@Entity

public class Card {

    @Basic

    private Suit suit;  // Suit is an enum Diamonds, Spades, ...

    

    @Basic

    private Rank rank;  // Rank is an enum Two - Ace

//...

}

If you'd like full source for a simple application based on the entities above email me at techhusky@gmail.com.  For more examples search the OpenJPA unit test source code for the @PersistentCollection annotation.  You'll find that OpenJPA persistent collection support is very configurable via a host of other OpenJPA annotations and can be used to persist other collection types in addition to the array.

-Jeremy

Support for OpenJPA?

One of the most common questions I get is how does IBM provide support for OpenJPA? Since the WebSphere JPA solution is built on top of the Apache OpenJPA project, how do customers get fixes to problems that reside in the OpenJPA code base?

The answer is quite simple -- via a WebSphere PMR. The WebSphere JPA team is active with the Apache OpenJPA project as contributors, committers, and members of the PMC. As problems are reported through the normal WebSphere PMR process, we will address the problems just like any other WebSphere problem. It doesn't matter whether the problem resides in the WebSphere JPA code base (extensions) or the Apache OpenJPA code base. Once the problem is discovered, a fix can be integrated into the appropriate Apache OpenJPA service stream and the resolution can be delivered as an iFix or as part of the next fixpack.

Bottom line, WebSphere will support the Apache OpenJPA code base that we ship just as if we had written it ourselves and, in many cases, we have. :-)

Kevin

Slice : OpenJPA for Distributed Persistence

Slice is now available as an integral part of released version of OpenJPA 1.2.0. Slice extends OpenJPA to transact and query against distributed, horizontally-partitioned, possibly heterogeneous databases. Using OpenJPA's excellent feature derivation framework, Slice offers any existing OpenJPA based application originally developed for single database to transparently upgrade to a database configuration where data is partitioned amongst multiple databases, without any change to the existing application.

Data partitioning is an effective scaling strategy against growing data volume. Many data sets are naturally amenable to partitioning by geographical region (e.g. Homes in each State), temporal interval (e.g. Order in each Month) or by the very nature of application such as multi-tenant, Software-as-Service hosting platforms. As data is distributed across months or states among different databases and Slice executes all critical database operations such as flush and commit in parallel -- the scaling characteristics is determined by size of the maximum database partition instead of the entire data set size. Moreover, Slice supports aggregate query operations such as SUM or MAX -- so that a standard JPQL query such as

select MAX(h.price) from Home h

will issue identical parallel queries across multiple databases, each storing data on Homes in individual state and find maximum of the results of each query and finally return the single maximum value as the result of the query.  

But how about the newly created instances? Which database partition will store a new record? This is, of course, specified by the application itself by implementing a single method of DistributionPolicy interface. The contract is simple: for any new persistent object as input argument, the method should return the name of the database partition. Slice when it encounters a new object during commit will call the user-defined DistributionPolicy implementation and store the new record to the appropriate partition. Slice also tracks the database origin of each persistent instance as they are loaded from different database partitions. So when the application modifies an instances in a transaction and commits -- Slice knows exactly which database partition will receive the update.

Welcome!

As the page header indicates, this blog will be used to discuss Java Persistence as it relates to the WebSphere Application Server. Specifically, we will be focusing on the Java Persistence API (JPA) and WebSphere's JPA solution. The WebSphere JPA solution is built on top of the Apache OpenJPA project. All of the authors on this blog are active with the development of the complete WebSphere JPA solution (including OpenJPA). But, we will adhere to the standard disclaimer that the views posted will be from us as individuals. :-)

Thanks for visiting and watch for new postings very soon.