Take the 2-minute tour ×

I had a few questions all related to the way an entity manager is created and used in an application with respect to Virtual Private Databases, which is a feature in Oracle DB which enables Row Level Security.

  1. In a session bean, we generally have the entity manager as a member, and its generally injected by the container. How is this entity manager managed by the container - I mean, if we want to implement a Virtual Private Database then we have to make sure that the Virtual Private Database-context remains valid for the entire user session, and we do not have to set this context everytime before we fire a query. (to include more verbiage here : a session bean implements a couple of functions and each of these functions uses the same entity manager; now, it should not be the case that we set the Virtual Private Database everytime in each of these functions which do some DB manipulations).

  2. Further to #1, since the entity manager is cached in the session bean, do we need to explicitly close the entity manager in any scenario? (like we do for JDBC connections?)

  3. Also, I was wondering what should be the use case(or design criteria) for using a JTA or a non-JTA datasource. Is the way we create an entity manager dependant on this?

To add w.r.t the requirement on VPD: It would be nice if the container managed EM can somehow be made to enforce the VPD per user. Note that EM is injected in here, so there should be a mechanism to set the VPD on the connection(and later retrieve the same connection for 'this' user in 'this' session).

Without an injected EM, i think using a reference to EMF and then setting the properties for the EM can be done. Something like : ((org.eclipse.persistence.internal.jpa.EntityManagerImpl)em.getDelegate()).setProperties

It would be an overkill, if the VPD is set everytime before the query is fired, rather the connection should 'maintain' the VPD context during the user's session and later release the connection (after clearing the VPD) back to the pool.

share|improve this question
add comment

1 Answer

In a session bean, an injected entity manager is container managed and by default transaction scoped.

This means when you call any method on the session bean and a transaction is started, the persistence context of the entity manager starts. When the transaction is committed or rollbacked it ends. There is thus no scenario in which you have to explicitly close the entity manager.

Furthermore, when there already is a transaction in progress, this is joined by default and when there already is a persistence context attached to said transaction it's propagated instead of a new one being created.

Stateful session beans have another option, and that's the extended persistence context. This one is coupled to the scope of the stateful bean instead of to individual transactions. You still don't have to do any closing yourself here.

Then, you can also inject an EntityManagerFactory (using @PersistenceUnit) and then get an entity manager from it: In that case you'll have an application managed entity manager. In this case you'll have to explicitly close it.

JTA datasources (transactional datasources) are by default used with container managed entity managers. The container takes care of everything here. non-JTA datasources are for situations where you need separate connections to a DB, possibly outside any running transaction, on which you can set auto commit mode, commit, rollback, etc your self.

These two different datasource types can be defined in orm.xml for a persistence unit. If you define a persistence unit with a non-JTA datasource, you typically create an entity manager for it using a factory and then manage everything your self.


Regarding the Virtual Private Database, what you seem to need here is a user specific connection per entity manager, but the normal way of doing things is coupling a persistence unit to a general data source. I guess what could be needed here is a datasource that's aware of the user's context when a connection is requested.

If you completely bypass the container and even largely bypass the JPA abstraction, you could go directly to Hibernate. It has providers that you can register globally like DriverManagerConnectionProvider and DatasourceConnectionProvider. If you provide your own implementations for these with a setter for the actual connection, you can ask these back from a specific entity manager instance just prior to using it, and then set your own connection in it.

It's doable, but needless to say a bit hacky. Hopefully someone else can give a more 'official' answer. Best would of course if Oracle provided an official plug-in for e.g. EclipseLink to support this. This document hints that it does:

TopLink / EclipseLink : Support filtering data through their @AdditionalCriteria annotation and XML. This allows an arbitrary JPQL fragment to be appended to all queries for the entity. The fragment can contain parameters that can be set through persistence unit or context properties at runtime. Oracle VPD is also supported, include Oracle proxy authentication and isolated data.

See also How to use EclipseLink JPA with Oracle Proxy Authentication.

share|improve this answer
Thanks for the explanation on JTA and non-JTA DS. It cleared the air for me. I am trying to better understand the use of "extended persistence context" ; in our application we do not have any transactions as such, but we want the EM to preserve its behaviour during the user's session - i.e, when the user fires his first query, then before this the VPD needs to be set. And this EM handle should be used for the rest of the user's session. Does extended persistence context solve this use-case? –  sprezzatura Jul 28 '11 at 18:27
Also, can you share as to how EntityManagerFactory can be injected? –  sprezzatura Jul 28 '11 at 18:31
Unfortunately I have no idea what VDP (Virtual Display Processing?) is, so I'm afraid I can't help you with that part. I think there should not be a particular need to explicitly preserve the behavior of an entity manager, namely it doesn't really have any behavior to be preserved. E.g. entityManager.find(12, Foo.class) will always return an instance of Foo with ID 12. There's nothing to customize here. Sorry if I misunderstand your use case. –  Arjan Tijms Jul 28 '11 at 19:12
>Does extended persistence context solve this use-case? - the extended persistence context will mainly keep the context open as long as the stateful bean lives. Making it session scoped is possible, but dangerous. The persistence context will remember evert entity it encounters and you'll most likely run out of memory quickly unless you're extremely careful. –  Arjan Tijms Jul 28 '11 at 19:14
VPD - Virtual Private Database. Its a feature in Oracle DB which enables Row Level Security. For this, i need to set the VPD context when the user logs and this context should be cleared when he logs out. So, if you see the EM needs to get only that specific DB connection for which the VPD has been set for this user. –  sprezzatura Jul 29 '11 at 5:16
show 3 more comments

Your Answer


