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.