[jpa-spec users] [jsr338-experts] Re: support for multitenancy

From: Gordon Yorke <>
Date: Wed, 18 Apr 2012 10:15:35 -0300

Also, if we add a javax.persistence.manditory-catalog and
javax.persistence.manditory-schema to the connection information that
should result in isolation/an alternate EMF and we have support for the
PAAS requirements. Allow the connection information to be specified
within a multi-tenant context and we have a clear path towards more
complex multi-tenancy functionality.

On 18/04/2012 10:05 AM, Gordon Yorke wrote:
> We can easily support this today without a new property as the
> connection information is not required to be defined within the
> persistence.xml file. Today a user can provide new connection
> information for a create EMF call and have a reasonable expectation
> that this EMF will be different from or isolated from another EMF with
> different connection information. As we move forward with
> multi-tenancy the specification should clarify the requirements with
> respect to providing alternate connection information and how it
> affects isolation of the EMF.
> --Gordon
> On 04/04/2012 5:47 AM, michael keith wrote:
>> We already have a solution to both of those problems, it's called an
>> EntityManagerFactory :-)
>> Really, though, an EMF is what isolates tenants from each other. The
>> problem is that people want to be able to define a single
>> configuration unit in their persistence.xml file and apply it to
>> multiple tenants, i.e vary it by tenant/connection information and
>> get a new EMF for it. People ask for this all the time. Support for a
>> persistence template is what I think would get us most of the way there.
>> For example, we could define a "javax.persistence.template" property
>> that could be passed to createEMF. One could create a new EMF from
>> the template simply by passing in the template and connection
>> information:
>> Map<String,String> map = new HashMap<String,String>();
>> map.put("javax.persistence.jdbc.driver", "...");
>> ...
>> map.put("javax.persistence.template", "SomePU");
>> EntityManagerFactory emf =
>> Persistence.createEntityManagerFactory("MyPU", map);
>> This would look for the persistence unit named "SomePU" and
>> dynamically create a new persistence unit/EMF named "MyPU", using all
>> the information from "SomePU" but overriding connection params with
>> the props passed in the map.
>> Container support is a little more involved and would require some
>> additional integration than what we are planning to add to EE 7.
>> -Mike
>> On 02/04/2012 10:39 AM, Steve Ebersole wrote:
>>> On Mon 02 Apr 2012 08:14:22 AM CDT, Deepak Anupalli wrote:
>>>> Linda,
>>>> Overall the proposal looks fine. However I was expecting an update to
>>>> JPA from the SaaS standpoint as well ("Application managed SaaS" in
>>>> your terminology :)), providing more flexibility to be able to work
>>>> with the prevailing database partitioning/sharding approaches.
>>>> -Deepak
>>> The SaaS approach certainly adds more complexity. While I certainly
>>> agree with Deepak here and think this is very widely useful, I guess
>>> as a group we need to decide if the extra complexity is "worth it".
>>> From my experience I can say that its actually not as complex as it
>>> looks at first glance, if that helps. Really it came down to 2
>>> things that would affect stock JPA:
>>> 1) Getting Connections. For the SHARED_TABLE approach, this is not
>>> any different. But for the other 2, the provider will need access
>>> to tenant-specific Connections. And to date, JPA has not
>>> standardized the contract for how providers obtain Connections which
>>> makes this a little tricky.
>>> 2) Segmenting shared cache. Caching of data in the process-scoped,
>>> shared cache needs to be segmented by each tenant since we are
>>> talking about the same process. Actually this is a concern anyway
>>> in implementing PaaS style multi-tenancy depending on how the cache
>>> provider is deployed, so not sure this is that big of a deal.
>>> Of course, as pointed out before, even if this is deemed outside the
>>> scope of JPA 2.1, nothing stops the individual providers from
>>> implementing this support.