GlassFish - World's first Java EE 7 Application Server


GlassFish Server Open Source Edition 3.2 - Persistence  One Pager

(template version 1.92)

1. Introduction

1.1 Project/Component Working Name:

GlassFish Server Open Source Edition 3.2 Persistence Service improvements

1.2 Name and Email Address of Author

Mitesh Meswani

1.3. Date of This Document:

Started: 04/25/11

2. Project Summary

2.1. Project Description:

GlassFish Persistence Services Improvements. These improvements will enable GlassFish persistence service to function more efficiently in a PaaS environment. Following improvements to persistence service are targeted for GlassFish 3.2

  • EclipseLink second level cache coordination using GMS as transport layer
  • Integrate EclipseLink mechanism to provide extensions into GlassFish

2.2. Risks and Assumptions:

  • EclipseLink second level cache coordination using GMS as transport layer
    • GMS API will work and scale as expected
  • Integrate EclipseLink mechanism to provide extensions into GlassFish
    • This feature is still being defined by EclipseLink team. It may not evolve into a shape that enables appservers to leverage it.

3. Problem Summary

3.1. Problem Area:

Improve GlassFish persistence service to function more efficiently in a PaaS environment

3.2. Justification:

Persistence, a core service for GlassFish need to function efficiently in a PaaS environment

4. Technical Description:

4.1. Details:

4.1.1 - EclipseLink second level cache coordination using GMS as transport layer

EclipseLink is the default persistence provider for GlassFish. In a clustered deployment, having EclipseLink's second level cache synchronized between nodes of a cluster should reduce probability of rollback due to stale data and thus improve throughput. EclipseLink provides a mechasnim to write plugin that hooks into second level cache events.  Goal of this project will be to implement this plugin using GMS as transport. Here are details of the planned implementation.

  • User can indicate that a Persistence Unit requires second level cache coordination using GMS by adding property "eclipselink.cache.coordination.protocol" with value "GMS" for a given persistence unit.
  • For such persistence units,  at app deployment a message listener will be registered with GMS. The API used is   
    GMSAdapter.registerMessageListener(String componentName, CallBack messageListener)

    Where componentName will be derived by combining ApplicationName + ModuleName + PuName. This ensures a unique channel per pu being deployed

  • At transaction commit, changes made in the transaction will be transmitted to the GMS group. The GMS API used for this will be 
    GroupManagementService.getGroupHandle().sendMessage(componentName, byte[] message)

    Where componentName will be derived as stated above and message will be constructed by serializing EclipseLink change set that represents changes made in the transaction into a byte[]

  • The message listener, on  receiving  the message will apply the received change set to the second level cache at destination 

4.1.2 - Integrate EclipseLink mechanism to provide extensions into GlassFish

EclipseLink team is defining feature that will enable providing extensions to a given entity.  This feature can be leveraged to provision MultiTenant apps into GlassFish such that each tenant can customize set of attributes for entities. The goal of this project will be to integrate this feature into GlassFish. Details will be added to this section once the EclipseLink feature solidifies. 

Both the features above will introduce compile time dependency on EclipseLink. A separate module parallel to jpa-connector will be created to host code that depends on EclipseLink

4.2. Bug/RFE Number:

4.4. In Scope:

  • Features described above
  • Work resulting from **Ad Hoc Cluster Deployment
    * Potential work resulting from JSR 338(Java Persistence 2.1)
    * Work resulting from MultiTenancy
    * Integrate EclipseLink 2.3
    * On going maintenance to persistence code
    4.4. Out of Scope:
  • Any features not mentioned above

4.5. Interfaces:

4.5.1 Public Interfaces

interface : javax.persistence (ver 2.1)

comments : From JSR 338

4.5.2 Private Interfaces

No new private interfaces that are observable externally.

4.5.3 Deprecated/Removed Interfaces:

None.

4.6. Doc Impact:

New documentation will be required to explain both 4.1.1 and 4.1.2

4.7. Admin/Config Impact:

None.

4.8. HA Impact:

Feature 4.1.1 will introduce more network traffic when cache coordination is turned on. This may impact HA performance. 

4.9. I18N/L10N Impact:

No impact.

4.10. Packaging, Delivery & Upgrade:

4.10.1. Packaging

A new module that represents code having dependency on EclipseLink will be introduced. This module needs to be shipped with GlassFish.

4.10.2. Delivery

No impact.

4.10.3. Upgrade and Migration:

No backward compatibility issues. 

4.11. Security Impact:

Like any other GMS communication in GlassFish, the change set being broadcasted may be intercepted.

4.12. Compatibility Impact

None

4.13. Dependencies:

4.13.1 Internal Dependencies

  • GMS

4.13.2 External Dependencies

  • EclipseLink v2.3

4.14. Testing Impact:

  • New automated tests should be developed by SQE to test the cache coordination feature

5. Reference Documents:

6. Schedule:

6.1. Projected Availability: