Jump to: navigation, search

Difference between revisions of "EclipseLink/DesignDocs/371950"

m (New page: =EclipseLink Metadata Cache= *[http://bugs.eclipse.org/371950 Enhancement Request 371950] {{warning|Work in progress|This analysis is in progress.}})
 
m
Line 2: Line 2:
 
*[http://bugs.eclipse.org/371950 Enhancement Request 371950]
 
*[http://bugs.eclipse.org/371950 Enhancement Request 371950]
 
{{warning|Work in progress|This analysis is in progress.}}
 
{{warning|Work in progress|This analysis is in progress.}}
 +
 +
==Purpose==
 +
This feature is to look at caching the metadata project so that the setup can avoid costs associated
 +
with reading in multiple orm.xml and annotation processing on entities within a
 +
persistence unit to rebuild it unnecessarily.
 +
 +
==Preliminary==
 +
The persistence unit in eclipselink-annotation-model.jar from JPA testing was chosen for investigation as it is the largest catch all unit in testing.
 +
Gathering acurate numbers to determine the costs and benifits are difficult as serialization is not posssible, and it is not yet understood what can be shared.  The org.eclipse.persistence.sessions.Project object is going to be used as a starting point as it is the underlying object that gets built from metadata processing and should contain all mapping information for a session/EntityManagerFactory.  Caching this object should be sufficient to prevent the need to reprocess the entire persistence unit as would be done from scratch.
 +
 +
The project cannot be serialized as is, and the process of serializing to a file would depend entirely on file io.  Initial numbers gathered indicate that creating a session from an existing project into the SessionManager, and then building an EntityManagerFactory/EntityManager from it takes 1/10 the time as building the initial persistence unit.  This number is incorrect though, as the test had to build the project by accessing the default persistence unit, thereby causing the agent to load and much of the static initialization to be done.  Comparing the time to load a default persistence unit to a subsequent unit within the same persitence.xml, the subsequent pu took 1/3 the time.  So 2/3 could have been due to costs that might not be able to be avoided through metadata caching - further testing is required. 
 +
 +
The next step is to modify the org.eclipse.persistence.sessions.Project and its references so that it can be reliably seralized and reused when serialized.

Revision as of 17:48, 17 February 2012

EclipseLink Metadata Cache

Warning2.png
Work in progress
This analysis is in progress.


Purpose

This feature is to look at caching the metadata project so that the setup can avoid costs associated with reading in multiple orm.xml and annotation processing on entities within a persistence unit to rebuild it unnecessarily.

Preliminary

The persistence unit in eclipselink-annotation-model.jar from JPA testing was chosen for investigation as it is the largest catch all unit in testing. Gathering acurate numbers to determine the costs and benifits are difficult as serialization is not posssible, and it is not yet understood what can be shared. The org.eclipse.persistence.sessions.Project object is going to be used as a starting point as it is the underlying object that gets built from metadata processing and should contain all mapping information for a session/EntityManagerFactory. Caching this object should be sufficient to prevent the need to reprocess the entire persistence unit as would be done from scratch.

The project cannot be serialized as is, and the process of serializing to a file would depend entirely on file io. Initial numbers gathered indicate that creating a session from an existing project into the SessionManager, and then building an EntityManagerFactory/EntityManager from it takes 1/10 the time as building the initial persistence unit. This number is incorrect though, as the test had to build the project by accessing the default persistence unit, thereby causing the agent to load and much of the static initialization to be done. Comparing the time to load a default persistence unit to a subsequent unit within the same persitence.xml, the subsequent pu took 1/3 the time. So 2/3 could have been due to costs that might not be able to be avoided through metadata caching - further testing is required.

The next step is to modify the org.eclipse.persistence.sessions.Project and its references so that it can be reliably seralized and reused when serialized.