*Management of shared schemas at design-time and runtime including DDL generation support for modified schemas.

+

*We need to integrate with work done for [http://wiki.eclipse.org/EclipseLink/DesignDocs/Multi-Tenancy Multi-Tenancy] - which is a specific implementation of the Extensibility API

+

*We need to integrate with work done for [http://wiki.eclipse.org/EclipseLink/DesignDocs/335601 Extensibility] - which is a general API for extending a schema at static (design-time) or dynamic(run-time). Multi-Tenancy is one implementation of this API.

**R20.1: Integrate with work for [http://wiki.eclipse.org/EclipseLink/DesignDocs/Multi-Tenancy Multi-Tenancy] - a specific implementation of the [http://wiki.eclipse.org/EclipseLink/DesignDocs/335601 Extensibility] API

+

**R20.2: Integrate with work for [http://wiki.eclipse.org/EclipseLink/DesignDocs/335601 Extensibility] - a generic API for Descriptor and Schema changes at design-time or run-time

+

* R21: Performance Monitor Integration

+

**Add API to work with the new [http://wiki.eclipse.org/EclipseLink/DesignDocs/321763 321763 Performance Monitor] introduced in EclipseLink 2.2

*Introduce Admin Role MBeans

*Introduce Admin Role MBeans

*Investigate Scripting support for configuration changes (WLS for WebLogic, Python for WebSphere, ? for JBoss, ? for GlassFish)

*Investigate Scripting support for configuration changes (WLS for WebLogic, Python for WebSphere, ? for JBoss, ? for GlassFish)

*WebLogic Server has several monitoring API join points that we can use either at the WebLogic MBean level or through events exposed to JRMC for servers running on the JRockit JVM. We will need to work closely with the WLS team to finalize the interfaces between EclipseLink and WLS.

*WebLogic Server has several monitoring API join points that we can use either at the WebLogic MBean level or through events exposed to JRMC for servers running on the JRockit JVM. We will need to work closely with the WLS team to finalize the interfaces between EclipseLink and WLS.

*R20.1: Integrate with work for [http://wiki.eclipse.org/EclipseLink/DesignDocs/Multi-Tenancy Multi-Tenancy] - which is a specific implementation of the Extensibility API

+

+

===Extensibility Support===

+

*R20.2: Integrate with work for [http://wiki.eclipse.org/EclipseLink/DesignDocs/335601 Extensibility] - which is a general API for extending a schema at static (design-time) or dynamic(run-time). Multi-Tenancy is one implementation of this API.

+

*For example see the section in the [http://wiki.eclipse.org/EclipseLink/DesignDocs/335601#Example_2 Use case] where the user of the Extensibility API makes changes at runtime to the existing schema by adding a relationship via to be determined set of new attributes or functions in the JMX management interface.

+

*Currently the '''Add''' action is supported. '''Delete''' and '''Update''' are not supported yet without an application shutdown.

+

====Extensibility via Flex Columns====

+

*Any new JMX API introduced into EclipseLink will follow the API exposed by the <font color="red">'''ExtensionManager'''</font> in the [http://wiki.eclipse.org/EclipseLink/DesignDocs/340192 340192 design document].

+

+

{|{{BMTableStyle}}

+

|-{{BMTHStyle}}

+

! JMX API function

+

! Extensibility API function

+

! Notes

+

|-

+

| addExtension(seqId, owningEntity, name, type )

+

| addExtension(ExtensionProperty)

+

| -

+

|-

+

| addExtension(seqId, owningEntity, name)

+

| addExtension(ExtensionProperty)

+

| Let EclipseLink auto choose the approprate data type

+

|-

+

| getExtension(id)

+

| ?(?)

+

| - this function lists an extension added via ''addExtension'', propagated from another client or added automatically at session creation time (possibly from persisted extensions in a previously passivated session or via '''@FlexExtension''' and '''@FlexColumn''' annotations at design time)

+

|-

+

| getExtensions()

+

| getExtensionFields()

+

| - this function lists extensions added via ''addExtension'', propagated from another client or added automatically at session creation time (possibly from persisted extensions in a previously passivated session)

+

|-

+

| getAvailableExtensionFields()

+

| getAvailableExtensionFields()

+

| - return remaining available ext fields

+

|-

+

| <font color="orange">''removeExtension(name)''</font>

+

| removeExtension(name)

+

| no effect until a redeploy

+

|-

+

| <font color="orange">''updateExtension(name)''</font>

+

| -

+

| no effect until a redeploy

+

|}

+

+

*Q) It is stated that remove and update are not supported at runtime without a redeploy. Do we mean they are supported but do not take effect until a redeploy?

+

===R23: JPA 2.0 Metamodel Exposure via JMX===

+

*20110321: After a quick discussion with Peter on exposing the [http://wiki.eclipse.org/EclipseLink/DesignDocs/340192#API Extensibility API] via JMX - it may be a better solution to expose the entire [http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api Metamodel] which would include any '''Extensible''' relationships added dynamically to the schema.

*The Metamodel is generated during the predeploy of the EntityManagerFactory for the persistence unit at runtime. There currently is internal API that can be used to regenerate the Metamodel in the case where dynamic relationships have been added to the model post-design-time. We will need to refactor this code to support viewing new mappings that were added via th Extensibility and Multi-Tenancy API's.

+

<source lang="java">

+

// EntityManagerFactoryImpl.java

+

/**

+

* INTERNAL: Convenience function to allow us to reset the Metamodel in the

+

* possible case that we want to regenerate it. This function is outside of

+

* the JPA 2.0 specification.

+

*

+

* @param aMetamodel

+

* @since Java Persistence 2.0

+

*/

+

public void setMetamodel(Metamodel aMetamodel) {

+

if (!this.isOpen()) {

+

throw new IllegalStateException(ExceptionLocalization.buildMessage("operation_on_closed_entity_manager_factory"));

+

}

+

this.setupImpl.setMetamodel(aMetamodel);

+

}

+

+

// User code

+

emf.setMetamodel(null); // clear Metamodel

+

emf.getMetamodel(); // regenerate Metamodel

+

</source>

+

+

=====JPA dependency in Core=====

+

*If we are going to store the actual '''Metamodel''' JPA 2.0 specification object in core/foundation on the session then we will need to introduce new dependency API. We may just need to copy out the types into our own proprietary native collection of types stored on the session.

+

*We will instead recreate the Metamodel maps for Entities, MappedSuperclasses and Embeddables as separate Maps on the session.

Document History

Date

Author

Version Description & Notes

20110214

Michael O'Brien

1.0 Initial draft started

Problem Statement

This enhancement details work that will be done to enhance our basic JMX management API and add additional support for diagnostics and analytics reporting. We will also look at adding features that will enable developers to more accurately capture runtime performance and diagnostics information, as well as tools to interpret that data.

There are two issues to this enhancement that separately deal with management and diagnostics reporting.

Management API

Our existing runtime JMX management API that is exposed through the services MBean in any of the SUN JConsole, JRockit JRMC, Oracle JRF Enterprise Manager or JBoss web based console is sufficient but needs to be enhanced.

Diagnostics API

Our existing runtime performance monitoring API could be enhanced with more JVM reporting - ideally that would not itself add overhead. This type of monitoring is currently done with JRockit - however it does not specifically target the JPA runtime API.

Scope

The scope of this issue is limited to the primary EE application servers that we currently support via JMX. These are WebLogic, WebSphere, GlassFish and JBoss. We may also extend support to SE applications and EJB 3.1 Lite containers running exclusively in the web container.

Session Management

Unified Metadata

Metadata mappings from Annotations and ORM XML

JPA 2.0 Metamodel

Session Cache

Query Cache

Dependency Injection Reference

Spring, Session, Message-Driven and Singleton beans that reference or have injections of EMFs or EMs

L1 Cache

L2 Cache

JDBC Database Configuration

Extensibility and Multi-Tenancy

Management of shared schemas at design-time and runtime including DDL generation support for modified schemas.

We need to integrate with work done for Multi-Tenancy - which is a specific implementation of the Extensibility API

We need to integrate with work done for Extensibility - which is a general API for extending a schema at static (design-time) or dynamic(run-time). Multi-Tenancy is one implementation of this API.

Requirements

Before we can decide on how and where we will enhance our management, analytics and diagnostics support we need to answer the following questions.

Q1) What do we currently provide

Q2) What are we going to with existing enhancment requests and how will we merge these with new requirements.

Q3) What new features can we provide to leverage new or existing management, performance and analytics tools that ship with the latest application server releases

Q4) What new features can we provide on top of Q1-Q3 that are specific to EclipseLink that go beyond what is currently available.

WebLogic Specific Requirements

WebLogic Server has several monitoring API join points that we can use either at the WebLogic MBean level or through events exposed to JRMC for servers running on the JRockit JVM. We will need to work closely with the WLS team to finalize the interfaces between EclipseLink and WLS.

WebSphere Specific Requirements

JBoss Specific Requirements

Spring TC Specific Requirements

Tomcat Specific Requirements

Generic Server Requirements

Ideally, any new API should be available to all supported EE servers (not just WebLogic) and optionally SE clients.

R: Expose PerformanceProfiler/PerformanceMonitor events through a new MBean generic to all EE servers

Constraints

non-WebLogic EE servers may not benefit from performance tracking provided by JRockit out of the box. These servers (WebSphere, JBoss and GlassFish) can however use the JRockit JVM with minimal configuration changes.

JRMC EclipseLink MBean method and attribute usage

JRMC EclipseLink MBean Trigger Rules

An example would be a trigger on Number of Objects In All Identity Maps. In my [distributed case study] after running the server for 24 hours we reach around 26000 objects in the identity map before the map is reset back to 6000. Therefore if we put a trigger at say 26000 we should see an event once a day on a load of 1 transaction per second.

JRMC Live Method Profiler for EclipseLink User and API classes

JRMC Live Exception Count for EclipseLink API and JPA Spec Exceptions

JRMC Diagnostic Commands for running EclipseLink user or System Threads

Performance Monitor

Data Partitioning

Multi-Tenancy Support

R20.1: Integrate with work for Multi-Tenancy - which is a specific implementation of the Extensibility API

Extensibility Support

R20.2: Integrate with work for Extensibility - which is a general API for extending a schema at static (design-time) or dynamic(run-time). Multi-Tenancy is one implementation of this API.

For example see the section in the Use case where the user of the Extensibility API makes changes at runtime to the existing schema by adding a relationship via to be determined set of new attributes or functions in the JMX management interface.

Currently the Add action is supported. Delete and Update are not supported yet without an application shutdown.

Extensibility via Flex Columns

Any new JMX API introduced into EclipseLink will follow the API exposed by the ExtensionManager in the 340192 design document.

JMX API function

Extensibility API function

Notes

addExtension(seqId, owningEntity, name, type )

addExtension(ExtensionProperty)

-

addExtension(seqId, owningEntity, name)

addExtension(ExtensionProperty)

Let EclipseLink auto choose the approprate data type

getExtension(id)

?(?)

- this function lists an extension added via addExtension, propagated from another client or added automatically at session creation time (possibly from persisted extensions in a previously passivated session or via @FlexExtension and @FlexColumn annotations at design time)

getExtensions()

getExtensionFields()

- this function lists extensions added via addExtension, propagated from another client or added automatically at session creation time (possibly from persisted extensions in a previously passivated session)

getAvailableExtensionFields()

getAvailableExtensionFields()

- return remaining available ext fields

removeExtension(name)

removeExtension(name)

no effect until a redeploy

updateExtension(name)

-

no effect until a redeploy

Q) It is stated that remove and update are not supported at runtime without a redeploy. Do we mean they are supported but do not take effect until a redeploy?

R23: JPA 2.0 Metamodel Exposure via JMX

20110321: After a quick discussion with Peter on exposing the Extensibility API via JMX - it may be a better solution to expose the entire Metamodel which would include any Extensible relationships added dynamically to the schema.

Analysis R23

The Metamodel is generated during the predeploy of the EntityManagerFactory for the persistence unit at runtime. There currently is internal API that can be used to regenerate the Metamodel in the case where dynamic relationships have been added to the model post-design-time. We will need to refactor this code to support viewing new mappings that were added via th Extensibility and Multi-Tenancy API's.

JPA dependency in Core

If we are going to store the actual Metamodel JPA 2.0 specification object in core/foundation on the session then we will need to introduce new dependency API. We may just need to copy out the types into our own proprietary native collection of types stored on the session.

We will instead recreate the Metamodel maps for Entities, MappedSuperclasses and Embeddables as separate Maps on the session.