users@jpa-spec.java.net

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

From: Pinaki Poddar <ppoddar_at_us.ibm.com>
Date: Wed, 4 Apr 2012 14:23:50 -0700

> an EMF is what isolates tenants from each other.
Agreed. Keeping this EMF:Tenant affinity to 1:1 would be the clean way to
proceed.

> Support for a persistence template is what I think would get us most of
the way there.
Agreed.


Regards --

Pinaki Poddar








From: michael keith <michael.keith_at_oracle.com>
To: jsr338-experts_at_jpa-spec.java.net
Cc: Steve Ebersole <steve.ebersole_at_redhat.com>, Deepak Anupalli
            <deepak_at_pramati.com>
Date: 04/04/2012 02:13 PM
Subject: [jsr338-experts] Re: [jpa-spec users] Re: support for
            multitenancy



No, the problem is the ability to do application-managed SaaS tenant
isolation conveniently. Your preconceived implementation approach is
apparently to share an EMF, but that is by no means the problem, just
one possible solution. I am proposing what I think is a much better one.

On 04/04/2012 9:28 AM, Steve Ebersole wrote:
> Sorry Mike, but you are wrong. The feature discussed as "SaaS" here
> would use the same EMF for multiple tenants. That's the whole
> point/problem.
>
>
> On 04/04/2012 03: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.
>>>
>