The thing EclipseLink is known most for is its object-relational support, but Clarke pointed out that EclipseLink also supports Java/XML binding with JAXB and MOXy, Service Data Objects, and database web services (scrape data out of database and generate JAX-WS web service for web deployment). Clarke described the various ways to access Eclipse Link (direct download, with GlassFish, and with Spring Framework were just some of the examples).
Clarke had a slide called "Understanding JPA" in which he showed the three pieces of JPA he commonly thinks of with "caching" joining them together. He said they spend much of their time working on the caching.
Clarke said that he used annotations in the slides because they make it easier to see the obvious fields being mapped. However, he also stated that significantly improved tooling has led many of his customers to return configuration back to XML.
In talking about JPA mapping, Clarke reminded the audience that JPA uses the "configuration by exception" approach to mapping Java objects to relational database tables. In his example of a JPA entity class, he demonstrated the @Convert and @Converter annotations that are specific to EclipseLink. He also mentioned the @PrivateOwned annotation.
When he talked about JPA querying, Clarke recommended using JPA named queries pattern and keeping named queries all in one place. The argument is that any changes to objects can all be reflected in one place rather than needing to be found when scattered among the code.
EclipseLink offers extensions to JPA for querying. This includes ability to query for read-only entities to improve performance and stored procedure/function support (including PL/SQL). EclipseLink also does have some specific extensions to JPQL: FUNC for direct database function, TREAT AS downcasts child classes in inheritance hierarchy, and query keys can be defined. EclipseLink extensions are also available to improve performance via explicit optimizations. EclipseLink provides query hints (an advertised "extension point" in the JPA specification) with the QueryHints class including QueryHints.FETCH (attribute joining) and QueryHints.BATCH. Clarke showed different slides that demonstrated how to take advantage of these query hints to reduce 3N+1 (301) queries to 1, 2, or 4 queries for his 100 purchase order example.
Clarke introduced "partial entities with attribute groups" as a new feature in JPA 2.1. Attribute Grouping allows the developer to define what happens to each field in an object and not just relationships. JPA has had FetchGroups for a while, but they are enhanced with JPA 2.1. EclipseLink offers "two level loading": everything you specify in the FetchGroup and anything else needed later in that same thread.
EclipseLink simplifies stored procedure usage with @NamedStorageProcedureQuery and @NamedStoredProcedureQueries annotations. The only place this EclipseLink-specific knowledge is captured is in the configuration.
JPA 2.0 adds the Cache interface to have some control over shared cache. The interface allows the JPA community to start working with the vendor-specific caching mechanisms that cannot be brought together yet. The @Cacheable annotation can be used to set shared-cache-mode property (ALL, NONE, ENABLE_SELECTIVE, DISABLE_SELECTIVE, ). EclipseLink has a default of cache set on. EclipseLink has two-layer caching approach in which EntityManager has a transaction cache and the EntityManagerFactory has a shared cache. EclipseLink's own @Cache annotation is used on a class level and configures shared cache handling of that entity; this does override the standard JPA caching setting. @Cache allows cache type based on Java reference types: FULL, WEAK, SOFT/HARD WEAK, and NONE. Can also specify cache size and expiration and disable shared caching with the @Cache annotation.
Clarke briefly mentioned EclipseLink's weaving. He introduced the @ChangeTracking annotation and its possible range of values. Several EclipseLink interfaces allow for finer grain control of how sessions are serialized and cached.
Clarke began wrapping up his session with a slide titled "Performance Tuning Summary."
I am generally mostly interested in sticking to a specification's standard approaches as much as possible because that is, after all, one of the big reasons for using a specification-based product. That being stated, there are times when for performance or other reasons, deviations must be used. JPA has been designed to allow for extensions with reduced effect on the standard parts and EclipseLink's design seems to have kept this approach in mind as well. Clarke's presentation was definitely focused on what EclipseLink provides as extensions to JPA (as he said it would at the beginning), but he also covered JPA basics and new features well in an effort to explain the EclipseLink extensions.
No comments:
Post a Comment