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

From: Deepak Anupalli <>
Date: Tue, 03 Apr 2012 14:45:19 +0530

On 02-04-2012 20:09, 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:

Steve I agree with you. We need to understand what does it take to roll
out such a support.
> 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.

This is always useful when you have a database partitioning scheme or a
topology where you have to deal with reads & updates to multiple
databases within an application.

> 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.
Completely agree. Web scale applications are architected to use systems
like Memcached to keep the cached data partitioned/segmented. In this
context, JPA vendors could think of integrating their shared caches with
systems like Memcached or JCache based implementations with a few
partitioning strategies.

I'm sure this is off-topic, probably we can start another thread and
discuss possible outcomes.