Skip to main content
Jump to: navigation, search

Difference between revisions of "EclipseLink/DesignDocs/Multi-Tenancy/TablePerTenant"

(Open/Future items)
Line 3: Line 3:
 
</div>
 
</div>
  
This feature will be a continuation of the multitenant feature that currently offers a SINGLE_TABLE type only. [http://wiki.eclipse.org/EclipseLink/Development/Indigo/Multi-Tenancy]
+
This feature will be a continuation of the multitenant feature that currently offers a SINGLE_TABLE type only. [http://wiki.eclipse.org/EclipseLink/Development/Indigo/Multi-Tenancy Multitenant]
  
 
== Table per tenant ==
 
== Table per tenant ==

Revision as of 14:24, 27 March 2012

This feature will be a continuation of the multitenant feature that currently offers a SINGLE_TABLE type only. Multitenant

Table per tenant

The goal of this feature is to allow multiple application tenants to have a their own individual table per tenant. Table per tenant tables are allowed with shareds table within the same persistence unit. A table per tenant policy is set per individual entities.

Requirements

  1. Support configuration of table per tenant entity types using EclipseLink specific annotations and/or eclipselink-orm.xml with the XML overriding the annotation.
    • Augment database queries to limit query results to the tenant per table
    • Ensure all INSERT, UPDATE, DELETE operations populate and limit their effect to the defined table per tenant
  2. Support accessing shared data at either the EntityManagerFactory or EntityManager
    • When using EMF the underlying cache must be unique to the provided tenant discriminator value(s)
  3. Schema generation??? TBD

Metadata Configuration

This document will focus only on the TABLE_PER_TENANT multi-tenant type. The type will enable individual tenant table(s) usage at the entity level using a context property that must be provided by the user.

  • The TABLE_PER_TENANT states that the table(s) (Table and SecondaryTable) for the given entity are individual tenant tables based on the user.
  • A TABLE_PER_TENANT type is used in conjunction with a table per tenant property definition to identify the user.

Important notes

  • Multi-tenant metadata can only be applied at the root level of the inheritance hierarchy when using a SINGLE_TABLE or JOINED inheritance strategy. A log warning will be issued otherwise.
  • It is possible to specify multi-tenant metadata within a TABLE_PER_CLASS inheritance hierarchy.

Short example

@Entity
@Table(name=“EMP”)
@Multitenant(TABLE_PER_TENANT)
public class Employee {
    ...
}

tenant1.EMP

EMP_ID VERSION F_NAME L_NAME GENDER
1 1 John Doe M

tenant2.EMP

EMP_ID VERSION F_NAME L_NAME GENDER
2 3 Jane Doe F

The following new EclipseLink metadata will be added.

Annotation usage

The new type will be added to possible value list for the existing @Multitenant annotation. See Multinancy for more configuration documentations of this annotation.

This means we will simple extend the MultitenantTenant enum to include TABLE_PER_TENANT.

public enum MultitenantType {
    /**
     * Specifies that table(s) the entity maps to includes rows for multiple tenants. 
     * The tenant discriminator column(s) are used with application context values to
     * limit what a persistence context can access.
     */
    SINGLE_TABLE, 
 
    /**
     * Specifies that the DB will handle the tenant filtering on all SELECT,
     * UPDATE and DELETE queries. Using this type assumes that the platform
     * used with your persistence unit does indeed support VPD.
     */
    VPD
 
    /**
     * Specifies that different tables are used for each tenant. The table scan be uniquely
     * identified by name, schema/tablespace.
     */
    TABLE_PER_TENANT 
}

XML usage

The multitenant-type XML element will be expanded to include the new type.

<xsd:simpleType name="multitenant-type">
  <xsd:annotation>
    <xsd:documentation>
      ...
    </xsd:documentation>
  </xsd:annotation>
  <xsd:restriction base="xsd:token">
    <xsd:enumeration value="SINGLE_TABLE"/>
    <xsd:enumeration value="VPD"/>
    <xsd:enumeration value="TABLE_PER_TENANT"/>
  </xsd:restriction>
</xsd:simpleType>

Metadata Processing Warnings and Exceptions

  • TBD

Property configuration and caching

At runtime the tenant per table property can be specified via a persistence unit definition, passed to a create entity manager factory call or set directly on the entity manager.

The order of precendence for tenant discriminator column properties is as follows:

  • EntityManager
  • EntityManagerFactory
  • Application context (when in a Java EE container)
<persistence-unit name="multi-tenant">
  ...
  <properties>
    <property name="eclipselink.table-per-tenant-id" value="gpelleti"/>
    ...
  </properties>
</persistence-unit>

Or alternatively (and most likely preferred) in code as follows:

HashMap properties = new HashMap();
properties.put(MULTITENANT_TABLE_PER_TENANT, gpelleti);
...     
EntityManager em = Persistence.createEntityManagerFactory("multi-tenant", properties).createEntityManager();
 
// OR set directly on the Entity Manager.
 
em.setProperty(PersistenceUnitProperties.MULTITENANT_TABLE_PER_TENANT, "gpelleti");

By default, tenants will share the EMF. If this is not the desired behavior it can be set through the following (exisintg property):

  • eclipselink.multitenant.tenants-share-emf

When set to false, users will need to provide a unique session name. Full caching is in effect at this point.

  • eclipselink.session-name

When the EMF is shared, by default, tenants will not share the cache, meaning table per tenant entities will have an ISOLATED setting. To allow these entities to share the cache, the following property can be set to true:

  • eclipselink.multitenant.tenants-share-cache

When the cache is shared, table per tenant entities will have a PROTECTED setting.

Swapping table per tenants during an active EntityManager is not allowed.

Core

The meat of the table per tenant strategy will be through database level settings and permissions and the table per tenant property will directly correlated with EclipseLink's descriptor table qualifier (which is added to all tables relating to that descriptor, table and secondary table)


NOTE: Id generation is shared across persistence units (see future section below).

Core/Runtime Exceptions

  • When a table per tenant is not set, a database exception will be thrown (invalid table name etc.)

Properties

The table per tenant property (eclipselink.table-per-tenant-id) will be available from:

  • org.eclipse.persistence.config.EntityManagerProperties.MULTITENANT_TABLE_PER_TENANT
  • org.eclipse.persistence.config.PersistenceUnitProperties.MULTITENANT_TABLE_PER_TENANT

Java example

EntityManager em = createEntityManager(MULTI_TENANT_PU);
em.setProperty("eclipselink.table-per-tenant-id", "gpelleti");
em.setProperty(EntityManagerProperties.MULTITENANT_TABLE_PER_TENANT, "gpelleti");

Querying

Full querying should be available to the user through the following entity manager operations:

  • persist
  • find
  • refresh

And the following queries:

  • named queries
  • update all
  • delete all

NOTE: EclipseLink will not modify, therefore, support multi-tenancy through named native queries. When using these types of queries within a multi-tenant environment, the user will need to be aware and handle any multi-tenancy issues (schemas) themselves directly in their native query. To all intent and purpose, named native queries should be avoided in a multi-tenant environment.

DDL generation

DDL generation will not be supported?? Need a table per tenant for all tenants to generate a table for each. TBD.

Open/Future items

Back to the top