Sorry Mike, but you are wrong. The feature discussed as "SaaS" here would use the same EMF for multiple tenants. That's the whole point/problem.
On 04/04/2012 03:47 AM, michael keith wrote:
We already have a solution to both of those problems, it's called an
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>();
EntityManagerFactory emf =
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.
On 02/04/2012 10:39 AM, Steve Ebersole wrote:
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
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.
[jsr338-experts] Re: [jpa-spec users] Re: support for multitenancy