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