Tuesday, October 28, 2008
Wednesday, September 24, 2008
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. :-)
Saturday, September 20, 2008
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.
Friday, September 19, 2008
Thanks for visiting and watch for new postings very soon.