[jsr338-experts] Re: support for multitenancy
- From: Steve Ebersole <steve.ebersole@...>
- To: jsr338-experts@...
- Cc: Deepak Anupalli <deepak@...>
- Subject: [jsr338-experts] Re: support for multitenancy
- Date: Mon, 02 Apr 2012 09:39:48 -0500
On Mon 02 Apr 2012 08:14:22 AM CDT, Deepak Anupalli wrote:
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.
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
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.