Bugzilla – Bug 5616
Implement Persistent Resource Using the Java Persistence API
Last modified: 2008-09-02 08:48:54
You need to
before you can comment on or make changes to this bug.
Objective: Implement Persistent Resource Using the Java Persistence API
Technologies: Java WS Core
Higher level services such as GRAM have requested support for RDBMS backed
persistent resources as a mechanism to support more reliable services.
Resources persisted in this manner are easily recoverable after a container
shutdown. In addition, having resources stored in a RDBMS allows for complex
querying. After an investigation, see bug 5551
(http://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=5551), JPA was chosen as an
underlying technology to implement the object-relational mapping required.
Simple service implementation
1. Develop interfaces for interacting with JPA
2. Code new ResourceHome implementation using JPA
3. Write documentation to explain to service developers how to use new
1. Updated code and unit tests.
Significant progress has been made on this campaign. The interfaces for
interacting with JPA have been created and the new ResourceHome implementation
is written. At the moment, however, this campaign is being set aside in order
to focus on bug 5613 (http://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=5613)
The scope of this bug has been clarified. As part of this bug a new Interface
called ResourceStore has been created which abstracts the storage of resources.
Three ResourceStore implementations are slated for completion. The first is a
simple In-Memory Store which has transient storage of resources in a
ConcurrentHashMap. When the container is shutdown, the resources in this Store
will disappear. The second Store implementation is a FileSystem store. This
store persists resources to the file system using the excellent Xstream
library. As a result, the resources are in human readable xml (if there is
such a thing). The resource will be saved in 3 separate files within a zip
file. There will be a document for the key, a document for the resource
lifetime (if applicable) and a document for the actual resource. This will
make searching for resources simpler and faster. The FileSystem will be
supported by cache services provided by the EHCache library. This is an
extremely high performance caching system which is commonly used in J2EE
applications. It also is compatible with Terracotta, so caching could be
distributed down the line. The final Store will use JPA as originally
specified in this bug, as the mechanism of storage. These three storage
mechanisms should provide most users what they need for persistence, but
implementing a custom ResourceStore is quite easy.
The implementation exists in th branch bug_5616. The base implementation is
fully backwards compatible with previous versions of java wsrf core. However,
a couple of changes have been made. The homemade version of the cache code has
been replaced with the excellent EHCache project. This provides a lot of
flexibility and reliability to our caching. Also, the synchronized collections
have been replaced with ConcurrentHashmap from the java concurrent backport.
The new persistence code has been implemented using the JPOX JDO implementation
and JPA implementation. The focus for the moment is on the JDO implementation
because it does not rely on Java 5, making this code backwards compatible.
However, the JPA (Java 5 persistence) is also available. JDO provides a rich
persistence mechanism with XML metadata.
Documentation on how to upgrade service persistence to use the new mechanism
will be available soon.
I have merged in the updates for this campaig into trunk. There are 4
implementations present: PersistentResource, Xstream, JDO, and JPA. They all
rely on the new ResourceStore interface which extends the current ResourceHome
interface. ResourceHomeImpl has been deprecated, although ResourceHome has not
and will not be. Existing code should work fine, but for more details on a
specific migration path to the new code, see
I see no commits to trunk from you and don't see any new classes in my trunk
checkout after a update -dP. I see commits to bug branch. Did you merge with
I specified the wrong link in my last update (and then got sick). Here is the
link for the docs.
>I specified the wrong link in my last update (and then got sick)
That will teach you to specify the wrong link.
Code has been merged into both trunk and the 4.2.0 branch