Skip to main content

[jsr338-experts] Re: support for multitenancy

  • From: "Werner Keil" <werner.keil@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Re: support for multitenancy
  • Date: Mon, 02 Apr 2012 16:50:43 +0200

I guess whether or not it makes it into JPA 2.1 is first up to the JPA Spec 
Lead, and where it may influence an overall Java EE 7 strategy up to those of 
EE 7. 

Luckily Linda is both, so it should be easier for her;-)

Werner

-------- Original-Nachricht --------
> Datum: Mon, 02 Apr 2012 09:39:48 -0500
> Von: Steve Ebersole <steve.ebersole@...>
> An: jsr338-experts@...
> CC: Deepak Anupalli <deepak@...>
> Betreff: [jsr338-experts] Re: support for multitenancy

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

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de


[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
 
 
Close
loading
Please Confirm
Close