Home » Java » EclipseLink Document Doesn't Explain "session"

EclipseLink Document Doesn't Explain "session"

Posted by: admin December 28, 2021 Leave a comment


I am trying to execute a query using EclipseLink following the crappy documentation at http://wiki.eclipse.org/Introduction_to_EclipseLink_Expressions_%28ELUG%29, but every time you need to execute an Expression it uses a variable called “session”, but no where does it explain where this “session” variable comes from. I already have a persistence.xml file and I can run a javax.persistence.Query on my database, so I know the connection works, but I can’t figure out where “session” comes from. A little help please?

A side question: I have been having a terrible time trying to get EclipseLink to work, even though everyone says how great it is compared to Hibernate. Is EclipseLink worth my time and frustration, or should I just scrap it and try something like Hibernate instead?



EclipseLink is born from the donation of Oracle Toplink to the Eclipse Foundation which, like Hibernate, is a proprietary persistence API and predates JPA. So, like Hibernate, it relies on a proprietary engine and proprietary concepts or abstractions. EclipseLink’s session is one of them (and is different from Hibernate’s session, which is more comparable to EclipseLink UnitOfWork).

That’s where JPA comes in. JPA provides a unified and standardized API that products like EclipseLink or Hibernate implement. This doesn’t mean they removed proprietary features and, if you don’t mind not being portable, you can use them. The posted link about Expressions is an example.

Now, if you want to use and learn JPA, you should stick to JPA (and this would be my advice). If you want to use proprietary features, you’ll have to learn things about the underlying persistence engine.

Regarding EclipseLink’s documentation, I can’t say I like it it even if I succeed in finding my way, maybe because I already have some experience with JPA. But this is subjective I guess and other people may have a different opinion (I disagree, but as I said, this is subjective).

However, Hibernate is undoubtedly more popular and has a wider community, more tutorials, etc and I find their documentation very good. I don’t know on what you based your choice but, from a community support point of view, Hibernate definitely wins. Just keep in mind that this doesn’t mean you won’t face frustration with Hibernate too 🙂


I suggest reading this.

In EclipseLink, there’re differents kinds of sessions. Without going into the details,
you can say that a session is something like a transaction. In a EclipseLink, a session is often a Unit Of Work, which knows what entities have changed/added/deleted or whatever.

You can retrieve such a session in EclipseLink, when invoking the following proprietary API on your JPA EntityManager:

//EntityManagerImpl has to be imported as org.eclipse.persistence.internal.jpa.EntityManagerImpl
Session session = ((EntityManagerImpl) entityManager).getActiveSession();

Before calling this, you should be sure that you’re within a transaction.


Much of the original documentation on the EclipseLink wiki pre-dates our JPA implementation. We are in the process of updating it to a much more usable JPA focused set of wiki pages. Most operations users need can be done with JPA and with our JPA 2.0 implementation even fewer needs arise to use the native sessions.

Can you let us know what you are trying to do and we can provide direct assistance or point you into the docs at the most appropriate content.

Although I am enjoying the stackoverflow interface the EclipseLink Forum offers the most active support from the project’s committers.



Is EclipseLink worth my time and frustration, or should I just scrap it and try something like Hibernate instead?

It is entirely up to you to judge whether it is “worth it” for you.

But I’d like to point out that wasted time and frustration when learning new technologies is just part of the job specification for a Software Engineer. If you cannot take it, you should seriously consider a less demanding career.