Revision as of 11:51, 18 September 2009

JPA 2.0: Property Processing

JPA 2.0 Root | bug 249023

Summary

The JPA 2.0 Specification provides functionality to set properties on the EntityManager at runtime. Before that feature can be completed we must define what properties can be set on the Entity Manager and when. This will allow use to clearly communicate to our customers how and when certain configurations can be applied. We must also update our property processing to ensure properties can be processed on a per property basis and that the property processing functionality is complete and available.

Work Estimate

• Define all properties and when they apply
  • 1 day
• Update property processing to account for lifecycle and validation
  • 4 days
• write tests to verify validation and lifecycle
  • 2 days

Functional Requirements

Two groups of properties

Only properties passed to createEM method guaranteed to take effect right away.

Some EntityManager properties could be applied to the unit of work which already exists, other can't. For each property that should be clearly listed in EntityManagerProperty class comments.

1. For each property of the first group, property value processed immediately as setProperty called.
   1. Each time getActivePersistenceContext is called the processed property value is set in the uow.
      1. Obvious optimization to add a flag indicating whether any of first group properties has changed since being last time set into the uow.

1. Properties of the second group processed and applied only when the new uow is created.
   1. User have to call em.clear() unless property applied to a brand new EntityManager.
      1. Even if the em is new, some application servers (was, oc4j) would have already created uow (they likely call em.joinTransaction()).

First group: properies applicable to existing uow

1. JOIN_EXISTING_TRANSACTION
2. PERSISTENCE_CONTEXT_CLOSE_ON_COMMIT
3. PERSISTENCE_CONTEXT_PERSIST_ON_COMMIT
4. PERSISTENCE_CONTEXT_COMMIT_WITHOUT_PERSIST_RULES
5. PERSISTENCE_CONTEXT_FLUSH_MODE
6. VALIDATE_EXISTENCE
7. FLUSH_CLEAR_CACHE

Second group: properies that require new uow

1. PERSISTENCE_CONTEXT_REFERENCE_MODE
2. ORACLE_PROXY_TYPE
3. EXCLUSIVE_CONNECTION_MODE
4. EXCLUSIVE_CONNECTION_IS_LAZY
5. JTA_DATASOURCE
6. NON_JTA_DATASOURCE
7. JDBC_DRIVER
8. JDBC_URL
9. JDBC_USER
10. JDBC_PASSWORD
11. CONNECTION_POLICY

getSupportedProperties limitation

The method doesn't cover (nor should it) the properties defined elsewhere.

1. ORACLE_PROXY_TYPE properties dictates usage of other Oracle Proxy Authentication properties:
   1. if the value OracleConnection.PROXYTYPE_USER_NAME then OracleConnection.PROXY_USER_NAME property should also be specified;
   2. if the value OracleConnection.PROXYTYPE_DISTINGUISHED_NAME then OracleConnection.PROXY_DISTINGUISHED_NAME property should also be specified;
   3. if the value OracleConnection.PROXYTYPE_CERTIFICATE then OracleConnection.OracleConnection.PROXY_CERTIFICATE property should also be specified;
2. Also OracleConnection.PROXY_USER_PASSWORD and OracleConnection.PROXY_ROLES may be used.
   1. May be more proxy properties will be defined in the future?
3. All of these properties handled by OracleConnection.openProxySession method
   1. Eclipselink passes all the properties to it, and the method processes the relevant properties, ignores all others.
4. getSupportedProperties currently returns only ORACLE_PROXY_TYPE, which I believe is correct.
   1. Even more precize would be not returning ORACLE_PROXY_TYPE unless the database platform is Oracle9Platform or higher.
   2. Return either JTA_DATASOURCE or NON_JTA_DATASOURCE depending on whether external transaction controller is used or not.

Existing Feature Impact

Design

Documentation

Testing

Open Issues