Eclipse Community Forums: Gemini » [Gemini JPA] - Unmanaged EntityManagerFactory

Help

Home

Home » Eclipse Projects » Gemini » [Gemini JPA] - Unmanaged EntityManagerFactory

Show: Today's Messages :: Show Polls :: Message Navigator

[Gemini JPA] - Unmanaged EntityManagerFactory [message #832649]

Fri, 30 March 2012 11:54

Eduardo Frazão

Messages: 123
Registered: January 2012

Senior Member

Hi all!
I was following this bug: 352708, (EntityManagerFactoryBuilder to create more than one EntityManagerFactory)

After its closed, and changes merged into source, I found this change in org.eclipse.gemini.jpa.proxy.EMFBuilderServiceProxyHandler class:

// If EclipseLink SESSION_NAME property specified then just create and return an EMF
        // NOTE: This will return an EMF that is not managed by Gemini.
        //       The caller will be responsible for managing it.
        if (props.get(PersistenceUnitProperties.SESSION_NAME) != null) {
                // Let EclipseLink do its thing and create an EMF. Just return it.
                debug("EMFBuilder found eclipselink.session-name - returning unmanaged EMF for props ", props);
                return super.createEMF(props);
        }

What is a unmanaged EntityManagerFactory? How can I deal with this?

Thanks by help!

Report message to a moderator

Re: [Gemini JPA] - Unmanaged EntityManagerFactory [message #832710 is a reply to message #832649]

Fri, 30 March 2012 13:41

Michael Keith

Messages: 243
Registered: July 2009

Senior Member

Hi Eduardo,

Yes, I will add this to the documentation when it gets out as part of the next release, but here are some hints to give you an idea about how to use it now.

In order to be able to create an additional EMF from the EMFB of a given persistence unit you need to pass the "eclipselink.session-name" property (with a value of your own choosing that is different for each EMF you create) into the createEntityManagerFactory() method on the builder. You will get back an EMF from EclipseLink that Gemini JPA will not manage. This means that if you ask for an EMF a second time, with the same parameters, etc, Gemini JPA will not return the same EMF. Gemini JPA does not keep hold of the EMF, so it is the callers responsibility to close and manage it if either the persistence unit bundle or Gemini JPA bundle go away. Like other EMFs created using the builder, it is the caller's responsibility to track the data source that is being used in the event that it goes away as well. Basically, Gemini JPA does a lot for you if you use the EMF services, but is a pretty thin veneer if you choose to use the builder, and even thinner if you use this feature since it is outside the model of what the OSGi JPA spec is trying to promote.

Hope this helps,
-Mike

Report message to a moderator

Re: [Gemini JPA] - Unmanaged EntityManagerFactory [message #832725 is a reply to message #832710]

Fri, 30 March 2012 14:00

Eduardo Frazão

Messages: 123
Registered: January 2012

Senior Member

Hi Mike!
My scenario is really a little different.
I'm using EclipseLink multitenancy feature, with single-table segmentation.
In this case, I got the TenantID after the user is loggedin on the Application. After this point, I create an EntityManagerFactory with the multitenant properties, and I set a Session name to use the SecondLevel cache of entities for this tenant.

This EntityManagerFactory is SessionScoped, so I can close it when the session go away. Thanks by allerting me, of the possibility of the domain bundle (with entities become inacessible). I will write some code to deal with it.
On my scenario, the GeminiJPA bundle is part of my "Runtime Boot". No other bundles goes up, until Gemini JPA and another bundles is ready (Its a PLAN inside Virgo Kernel UserRegion config).

Do you think that it is a good approach with Gemini JPA + EclipseLink Dynamic Multitenancy?

Thank you by providing this clarifications even before write the official documentation! The support of Gemini JPA comunity/maintainers is really good!

Report message to a moderator

Re: [Gemini JPA] - Unmanaged EntityManagerFactory [message #832836 is a reply to message #832725]

Fri, 30 March 2012 16:45

Michael Keith

Messages: 243
Registered: July 2009

Senior Member

That will work, but from what you are saying I'm not sure you even need to use the multiple EMF feature. If all of the tenants are using the same database and tables then why don't you just include all of the connection information in the persistence descriptor and look up the EMF service?

Report message to a moderator

Re: [Gemini JPA] - Unmanaged EntityManagerFactory [message #833510 is a reply to message #832836]

Sat, 31 March 2012 16:09

Eduardo Frazão

Messages: 123
Registered: January 2012

Senior Member

Because the TenantID is dynamic.
I can have N number of tenants, that will be dynamically created by admins of the application. Tenants is only a record on a tenants table, that will be our client accounts. After that, several logins can be created for each tentant account.

Once a user is loged-in, the application discover what tenant it belongs, and share this information on the session scope (an HTTP Session). When a service is needed, a session scope entitymanagerfactory is built, and this shared tenant id is injected into EMF properties.

I cant found a way to use a static config in persistence.xml to reach this scenario.

Here is how I build my properties:

public class DynamicEMFPropertyMapFactoryBean {

	private LoggedUserContext loggedUserContext;
	
	public DynamicEMFPropertyMapFactoryBean(LoggedUserContext loggedUserContext) {
		this.loggedUserContext = loggedUserContext;
	}
	
	public Map<String, Object> getPropertyMap() {
		HashMap<String, Object> map = new HashMap<String, Object>();
		
		Integer empresaId = (loggedUserContext.getTenantId() == null) ? 0 : loggedUserContext.getTenantId();
		
		// Connection INFO
		map.put(PersistenceUnitProperties.TARGET_DATABASE, "PostgreSQL");
		map.put(PersistenceUnitProperties.JDBC_DRIVER, "org.postgresql.Driver");
		map.put(PersistenceUnitProperties.JDBC_URL, "jdbc:postgresql://localhost:5432/weld");
		map.put(PersistenceUnitProperties.JDBC_USER, "postgres");
		map.put(PersistenceUnitProperties.JDBC_PASSWORD, "postgres");
		map.put(PersistenceUnitProperties.CONNECTION_POOL_MIN, String.valueOf(2));
		map.put(PersistenceUnitProperties.CONNECTION_POOL_MAX, String.valueOf(5));
		
		// Multitenancy
		map.put("tenant.id", empresaId);
		map.put("eclipselink.tenant-id", empresaId);
		map.put("eclipselink.session-name", "multitenancy-session-"+String.valueOf(empresaId));
		
		// Weaving
		map.put(PersistenceUnitProperties.WEAVING, String.valueOf(true));
		
		// Logs
		map.put(PersistenceUnitProperties.LOGGING_EXCEPTIONS, String.valueOf(true));
		map.put(PersistenceUnitProperties.LOGGING_LEVEL, "warning");
		
		return map;
	}
	
}

Report message to a moderator