Scribd
Upload
442 views4 pages

EclipseLink JPA

EclipseLink is an open source framework from Eclipse that provides persistence services for interacting with databases, web services, and other data sources. It supports standards like JPA and can be used in Java EE, SE, and OSGi environments. EclipseLink has extensive support for integrating with Oracle databases, including features like LOBs, XMLType, timestamps, batch writing, object-relational mappings, PL/SQL types and stored procedures. Stored procedures and triggers are also supported through JPA annotations and API classes. The SQL for a JPA query can be viewed in the log or programmatically retrieved using the DatabaseQuery API. Both sides of a bi-directional relationship must be maintained in JPA.

Uploaded by

vijayroom
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
442 views4 pages

EclipseLink JPA

EclipseLink is an open source framework from Eclipse that provides persistence services for interacting with databases, web services, and other data sources. It supports standards like JPA and can be used in Java EE, SE, and OSGi environments. EclipseLink has extensive support for integrating with Oracle databases, including features like LOBs, XMLType, timestamps, batch writing, object-relational mappings, PL/SQL types and stored procedures. Stored procedures and triggers are also supported through JPA annotations and API classes. The SQL for a JPA query can be viewed in the log or programmatically retrieved using the DatabaseQuery API. Both sides of a bi-directional relationship must be maintained in JPA.

Uploaded by

vijayroom
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

EclipseLink JPA

EclipseLink is the open source Eclipse Persistence Services Project from the Eclipse Foundation. The software provides an extensible framework that allows Java developers to interact with various data services, including databases, web services, Object XML mapping (OXM), and Enterprise Information Systems (EIS). EclipseLink supports a number of persistence standards Eclipse Persistence Services Project (EclipseLink) is a comprehensive persistence framework delivering a set of persistence services based around leading standards with advanced extensions. Consumers can use EclipseLink within Java EE, SE, and OSGi/Equinox environments.

How is EclipseLink integrated with the Oracle database?


EclipseLink is completely independent from, but also tightly integrated with the Oracle database. EclipseLink has extended support for most Oracle SQL, JDBC and database extensions. EclipseLink's extended support for the Oracle database includes:
y y y y y y y y y y y y y y y

LOB's NChar's XMLType's TIMESTAMP (TZ, LTZ)'s Native batch writing Structured object-relational data-types PLSQL data-types and stored procedures VPD, RAC, proxy authentication XDK XML parser Hierarchical selects (Select by prior) Returning clause Flashback history and queries Stored procedures, output parameters and output cursors Stored functions Oracle AQ

How to access the JDBC connection?


Sometimes when using JPA it may be required to have lower level access to your database through JDBC. If you are using a JEE DataSource, you can just access the same DataSource that JPA uses, if it is a JTA DataSource it will be in the same transaction context as JPA. If you are not using a DataSource, or want the same connection in the same transaction as JPA, you can obtain the JDBC Connection from the EntityManager.

Are stored procedures and triggers supported?


EclipseLink has extended support for stored procedures and triggers. Stored procedures are support through the @NamedStoredProcedureQuery, @NamedStoredFunctionQuery, @NamedPLSQLStoredFunctionQuery, @NamedPLSQLStoredProcedureQuery, StoredProcedureCall, StoredFunctionCall, PLSQLStoredProcedureCall, and PLSQLStoredFunctionCall classes. The following stored procedures features are supported:
y y y y y y y y y y y y y

IN parameters OUT parameter INOUT parameters result sets CURSOR OUT parameters Object-relational datatypes (Struct, Array) Oracle PLSQL types such as TABLE, RECORD, BOOLEAN Using a stored procedure in a named query Using a stored procedure in a dynamic query Using a stored procedure to override an Entity's persist, update, remove or find query. Using a stored procedure to override a mapping's select, insert or delete query. Stored functions Oracle, SQL Server, MySQL, Sybase, DB2, other stored procedure capable platforms

Triggers can be used in the tables being processed by EclipseLink. If a trigger is updating data required back in the application, or the id, the @ReturnInsert, @ReturnUpdate or ReturningPolicy can be used the return the values updated by the trigger.

How to get the SQL for a Query?


To see the SQL for a JPA Query you can enable logging on FINE or lower. To get the SQL for a specific Query at runtime you can use the DatabaseQuery API.
Session session = em.unwrap(JpaEntityManager).getActiveSession(); DatabaseQuery databaseQuery = ((EJBQueryImpl)query).getDatabaseQuery(); databaseQuery.prepareCall(session, new DatabaseRecord()); String sqlString = databaseQuery.getSQLString();

This SQL will contain ? for parameters. To get the SQL translated with the arguments you need a DatabaseRecord with the parameter values.
Session session = em.unwrap(JpaEntityManager).getActiveSession(); DatabaseQuery databaseQuery = ((EJBQueryImpl)query).getDatabaseQuery();

String sqlString = databaseQuery.getTranslatedSQLString(session, recordWithValues);

Do I have to maintain both sides of a bi-directional relationship?


Yes, you need to maintain both sides of the relationship in JPA. It is a common problem that an application does not do this, and then sees inconsistent objects afterwords. This is normally not done by mistake, but is also done on purpose, normally with a ManyToOne/OneToMany relationship, where the application programmer wants to avoid the cost of reading in the OneToMany collection, especially if it is large. If you are updating a child in a OneToMany, then you just need to find() it, and update it, or use merge(). You do not need to merge() or modify the parent or its children relationship. If you are adding a new child, then you need to persist() or merge() it, set its parent to the one from the current persistence context using find() (merge can do this, but if your parent is transient, or nulled out, then you need to do this yourself, and if the parent's children are transient or nulled out, then you need to be careful it is not merged or cascaded). You also need to add the child to the parent's children (otherwise it will not be there in the current persistence context, or possibly future ones if you are using a shared cache). If you are deleting a child, then you need to call remove() on it, unless you have set the relationship to deleteOrphans. You also need to remove it from the parent's children, (otherwise it will still be there in the current persistence context, or possibly future ones if you are using a shared cache). There are alternatives to adding and removing the child though, if you want to avoid the cost of reading the children:
y y y y y

If you are using LAZY relationship, a List (it is also possible with Set, but there can be issues), and weaving (static or dynamic), then add() and remove() will not instantiate the children. If the children is not something you want to ever read, then consider not mapping it, just query it if needed. If the parent's children is not instantiated, you could avoid adding the child. (see PersistenceUnitUtil.isLoaded()). You can call refresh() on the parent after the commit to reset its children. You can avoid adding the child if you clear or throw away your persistence unit, and are not using a shared cache.

EJB3 vs Hibernate vs Toplink vs OpenJPA


EJB3 entity beans mean JPA beans. As such, this is 'just' a specification of the API, behaviour, semantics. JPA by itself is not usable, it requires someone to implement the specification. Such implementations (called JPA providers) are: Oracle TopLink Essentials* (reference implementation of JPA1), Hibernate (JPA1 and JPA2 recently with HB 3.5), EclipseLink (JPA1 and reference implementation of JPA2, TopLink donated by Oracle to Eclipse). There are others. Different implementations are used in different application servers: Glassfish v2.1 uses TopLink Essentials, JBoss uses HIbernate, Glassfish v3 uses EclipseLink. The idea is that you write your application against interfaces on GF 3 and then you are able to deploy and use it in JBoss AS 6, for instance - this requires that you don't use any provider specific functionality. If you do, you would have to bundle the provider with your application or simply rewrite parts of the app for the new runtime. When comparing EJB3 vs. Hibernate, people mean JPA vs. Hibernate native API. Hibernate native has much functionality that didn't make it to JPA (EclipseLink as well), so if you need it, you might consider 'jailbreaking' from JPA. All project that I was on started with JPA, and if necessary breaked out (but not often). * TopLink and TopLink Essentials - TopLink was a product by Oracle (as such I think it was closed source, but I am not sure), TopLink Essentials was an Open Source subset of TopLink that restricted itself to only implement what JPA requires. TopLink was later donated to Eclipse and is now an Open Source product under the name EclipseLink, and serves as the reference implementation for JPA2. It is worth checking out.

You might also like