Jump to: navigation, search

EclipseLink/DesignDocs/368490

< EclipseLink‎ | DesignDocs
Revision as of 16:46, 13 January 2012 by Christopher.delahunt.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Refresh Metadata through RCM

Enhancement request: bug 368490

extension to ER 340192: Descriptor Extensibility by Flex Columns

Summary

This feature is to allow refresh commands to be progated to the cluster to signal that the metadata has changed.

Why use this feature?

When metadata changes, it can take time to manually call refreshMetadata on each server's EntityManagerFactoryWrapper instance. This feature can allow this to be called on a single instance and progated to the cluster. A single instance such as an admin application or PAAS Manager could also just broadcast the command directly to the cluster.

How to use this feature

The "eclipselink.metadata-source.send-refresh-command" property defaults to true. This means that the only requirements to having refresh commands propogated to the cluster are to have RCM configured, and to have the deploy-on-startup property set. Ie <property name="eclipselink.deploy-on-startup" value="true"/>


Requirements

  • Must be able to trigger or operate similar to calling EntityManagerFactoryWrapper's refreshMetadata() on all subscribed EntityManagerFactories.

Design

PersistenceUnitProperties:

public static final String METADATA_SOURCE_RCM_COMMAND = "eclipselink.metadata-source.send-refresh-command";

which is required to turn on/off the sending of commands through JPA setup.

The command itself will need to call public EntityManagerSetupImpl refreshMetadata(Map properties) on EntityManagerSetupImpl. To avoid Core having a dependencies on JPA, an Interface is used:

public interface MetadataRefreshListener { 
    public void triggerMetadataRefresh(Map properties);
}

EntityManagerSetupImpl will then extend this interface, which be stored in the AbstractSession to be used by any received MetadataRefreshCommand objects. AbstractSession will make the listener available through acessors: public MetadataRefreshListener getRefreshMetadataListener() public void setRefreshMetadataListener(MetadataRefreshListener metadatalistener)

The properties used in refreshMetadata will also be progated across and so stored in the MetadataRefreshCommand:

public class MetadataRefreshCommand extends Command { 
 
     protected Map properties;
 
     public MetadataRefreshCommand(Map properties) {
         super();
         this.properties = properties;
     }
 
     @Override
     public void executeWithSession(AbstractSession session) {
         MetadataRefreshListener listener = session.getRefreshMetadataListener();
         if (listener&nbsp;!= null) {
             listener.triggerMetadataRefresh(properties);
         }
     }

Limitations

  • The session will not be registered for RCM until login, and so may miss MetadataRefreshCommand that should apply unless "eclipselink.deploy-on-startup" is set to true.


Testing

RCM testing already verifies that commands are sent when RCM is configured. This requires testing that MetadataRefreshCommand will trigger metadata refresh/reload