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