Skip to main content

[jsr338-experts] Re: support for multitenancy

  • From: Gordon Yorke <gordon.yorke@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Re: support for multitenancy
  • Date: Wed, 18 Apr 2012 10:05:34 -0300

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.
--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.



[jsr338-experts] Re: support for multitenancy

Deepak Anupalli 04/02/2012

[jsr338-experts] Re: support for multitenancy

Steve Ebersole 04/02/2012

[jsr338-experts] Re: support for multitenancy

Werner Keil 04/02/2012

[jsr338-experts] Re: support for multitenancy

Deepak Anupalli 04/03/2012

[jsr338-experts] Re: support for multitenancy

Steve Ebersole 04/04/2012

[jsr338-experts] Re: support for multitenancy

michael keith 04/04/2012

[jsr338-experts] Re: support for multitenancy

Steve Ebersole 04/04/2012

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

michael keith 04/04/2012

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

Pinaki Poddar 04/04/2012

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

Steve Ebersole 04/04/2012

[jsr338-experts] Re: support for multitenancy

Gordon Yorke 04/18/2012

[jsr338-experts] Re: support for multitenancy

Gordon Yorke 04/18/2012

[jsr338-experts] Re: support for multitenancy

Linda DeMichiel 04/02/2012

[jsr338-experts] Re: support for multitenancy

Deepak Anupalli 04/03/2012

<Possible follow-up(s)>

[jsr338-experts] Re: support for multitenancy

Pinaki Poddar 04/04/2012

[jsr338-experts] Re: support for multitenancy

michael keith 04/04/2012

[jsr338-experts] Re: support for multitenancy

Steve Ebersole 04/10/2012

[jsr338-experts] Re: support for multitenancy

Linda DeMichiel 04/10/2012

[jsr338-experts] Re: support for multitenancy

Steve Ebersole 04/10/2012

[jsr338-experts] Re: support for multitenancy

Linda DeMichiel 04/10/2012

[jsr338-experts] Re: support for multitenancy

Steve Ebersole 04/10/2012
 
 
Close
loading
Please Confirm
Close