Multi-Tenancy

The goal of this feature is to allow multiple application tenants to share the same schema using tenant discriminator column(s). It is for shared 'striped' database data and this feature will target only the SINGLE_TABLE solution outlined in the new annotation and xml metadata to follow. The TABLE_PER_TENANT strategy will not be addressed in this feature doc.

Requirements

Support configuration of shared multi-tenant entity types using EclipseLink specific annotations and/or eclipselink-orm.xml with the XML overriding the annotation.

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)

Support the tenant discriminator column(s) being:

un-mapped

mapped

Support schema generation including the specified tenant discriminator column(s).

Metadata Configuration

This document will focus only on the SINGLE_TABLE multi-tenant type. The type will enable shared tenant table(s) usage at the entity level using one or more columns associated with persistence unit or context property values that must be provided by the user.

Highlights

The SINGLE_TABLE states that the table(s) (Table and SecondaryTable) for the given entity is shared ("striped") amongst tenants.

A SINGLE_TABLE type is used in conjunction with tenant discriminator column(s).

Annotation usage

The new @Multitenant annotation is specified at the entity (or mapped superclass level). To enable multi-tenancy on a given entity the @Multitenant must be specified (@see minimal configuration).

From the multi-tenant type, its companion annotation(s) (e.g. @TenantDiscriminatorColumn) are determined and processed accordingly.

Multitenant metadata can be applied at the mapped superclass level. When applied at this level it is applied to all sub-entities unless they specify their own multi-tenant metadata. Note: multi-tenancy and its companion annotation(s) are homogeneous and will continue to be when new types are included. Meaning the following:

MyEntity's @TenantDiscriminatorColumn is ignored and the defaults will apply to the @Multitenant specification from MySuperclass (where the tenant discriminator column is defaulted).

Annotation definitions

@Target({TYPE})
@Retention(RUNTIME)public @interface Multitenant {/**
* (Optional) Specify the multi-tenant strategy to use.
*/
MultitenantType value()default MultitenantType.SINGLE_TABLE;}
@Target({TYPE})
@Retention(RUNTIME)public @interface TenantDiscriminatorColumn {/**
* (Optional) The name of column to be used for the discriminator.
*/String name()default"TENANT_ID";/**
* (Optional) The name of the context property to apply to the
* tenant discriminator column.
*/String contextProperty()default"eclipselink.tenant-id";/**
* (Optional) The type of object/column to use as a class discriminator.
* Defaults to {@link DiscriminatorType#STRING DiscriminatorType.STRING}.
*/
DiscriminatorType discriminatorType()default DiscriminatorType.STRING;/**
* (Optional) The SQL fragment that is used when generating the DDL
* for the discriminator column. Defaults to the provider-generated
* SQL to create a column of the specified discriminator type.
*/String columnDefinition()default"";/**
* (Optional) The column length for String-based discriminator types.
* Ignored for other discriminator types.
*/int length()default31;/**
* (Optional) The name of the table that contains the column.
* If absent the column is assumed to be in the primary table.
*/String table()default"";/**
* Specifies that the tenant discriminator column is part of the primary
* key definition of the table.
*/boolean primaryKey()defaultfalse;}
@Target({TYPE})
@Retention(RUNTIME)public @interface TenantDiscriminatorColumns {/**
* (Required) One or more <code>TenantDiscriminatorColumn</code> annotations.
*/
TenantDiscriminatorColumn[] value();}publicenum 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 different tables are used for each tenant. The table scan be uniquely
* identified by name, schema/tablespace.
*/
TABLE_PER_TENANT
}

XML usage

The multitenant metadata in XML will be available at within the entity and mapped superclass element. When support for other multi-tenant types are added, their companion metadata should be surrounded by an xml choice element.

Minimal Configuration

All parts of the multi-tenant and tenant discriminator metadata are defaulted (see annotation definition above), however to enable multi-tenancy @Multitenant or <multitenant> must be specified. Therefore the minimal configuration is:

@Entity
@Table(name="EMP")
@Multitenant
public Employee(){
...
}// NOTE: The following example is NOT a minimal configuration. This would lead to no multi-tenancy as the solo @TableDiscriminator is // ignored since @Multitenant was not specified.
@Entity
@Table(name="EMP")
@TenantDiscriminatorColumn
public Employee(){
...
}

Persistence unit and entity mappings defaulting

Along with the availability from the entity and mapped superclass levels, the new metadata will available at the following levels to provide defaults. Usage at the these levels follows similar JPA metadata defaulting and overriding rules.

persistence-unit-defaults

entity-mappings

persistence-unit-defaults

In the eclipselink-orm.xml, it is possible to specify default tenant discriminator column metadata through the persistence unit metadata defaults. When defined at this level, it will apply to all entities of the persistence unit that have specified a multi-tenant type of SINGLE_TABLE minus those that specify their own tenant discriminator metadata.

Note: with no defaults, an entity not marked with multi-tenant metadata will not use any multi-tenancy strategy.

entity-mappings

Alternatively, users may specify tenant discriminator column metadata at the entity-mappings level as well which would override a persistence unit default and apply itself to all entities with a multitenant type of SINGLE_TABLE of the given mapping file (unless an individual entity has specified its own tenant discriminator metadata).

Mapped vs. Unmapped Tenant Discriminator

When a tenant discriminator column is mapped, its associated mapping attribute should be marked as read only. If it is not, an exception will be raised. With this restriction in place, a tenant discriminator column can not be part of the entity identifier (it can only be part of the primary key specification on the database, see the annotation definition above)

On persist, the value of the mapped tenant discriminator column mapping is populated from its associated context property.

Both mapped and unmapped properties are used to form the additional criteria when issuing a select query.

A mapped tenant discriminator column who's attribute is not marked read only will throw an exception.

Defaults will always apply even when there are multiple tenant discriminators and no exception above has been raise. This allows users to map several columns for the same property. E.g. The code below would default the property name to "eclipselink.tenant-id" and states it should be writing the TENANT column for both the EMPLOYEE and SALARY table.

Entity Manager Factory

At this level, users will be required to provide a unique session name through the "eclipselink.session-name" property to ensure a unique server session (and cache) is provided for each tenant. This allows for user defined properties (without any prefixing). In further iterations we will look to augment the session name automatically for the user based on their tenant property values (or something thereof).

Shared Entity Manager Factory

A shared entity manager factory will be configured by default. When using a shared entity manager factory, by default the cache (L2) is not shared, meaning multitenant entities will have an ISOLATED cache setting. If users want to share the cache, setting the eclipselink.multitenant.tenants-share-cache to true will allow this and multitenant entities will have a PROTECTED cache setting.

To not share the entity manager factory users can set the eclipselink.multitenant.tenants-share-emf property to false.

Swapping tenant ID during an active EntityManager is not allowed.

Entity Manager

At this level, users will be required to specify the caching strategies as the same server session can be employed for each tenant. Users may decide to us an isolation level here etc to ensure no 'shared' tenant information exists in the L2 cache. These settings are set when creating the entity manager factory.

Core

The tenant dsicriminator column(s) will be initialized during the pre-initialization of each descriptor of the persistence unit.

Those columns will then be applied in two places.

We will leverage the current additional join expression from the DescriptorQueryManager to filter tenants. This is similar to the Additional Criteria feature. During postInitialization of the descriptor query manager after we have appended the additional criteria (if there is some), we will append the tenant discriminator column(s) to the additional join expression.

The tenant discriminator column value(s) will be added as arguments when issuing queries.

For inserts, we will append the tenant discriminator column(s) and value(s) when building the row representation of an object. This is done in the following methods from ObjectBuilder (Note: this is similar to the handling of the discriminator column within an inheritance hierarchy)

buildRow

buildRowForShallowInsert

buildRowForUpdate

buildRowWithChangeSet

buildTemplateInsertRow

NOTE: When the tenant discriminator column is mapped, it need not be added to the row. Only its value should be populated if it has not already been done.

For reading, to enable the additional criteria (tenant discriminator columns) we will need to modify the ReadObjectQuery and ReadAllQuery slightly in the prepareForExecution method.

There we will clone the translation row (if need be) and append the tenant discriminator columns to it before execution.

The tenant discriminator column(s) are assumed to exist on the primary table. If using secondary tables the tenant discriminator column metadata must specify the table if it is not on the primary.

Tenant discriminator column(s) are not expected for the following tables (which refer back to their related entity through a primary key association):

Java example

Querying

The tenant discriminator column and value will be supported 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 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 need to support the generation of tenant discriminator columns (for all necessary tables). The DDL generation of columns is based off the descriptor's columns. During pre-initialization we therefore need to ensure that our tenant discriminator columns are built and added to this list (if they are NOT mapped columns). This should be done after the descriptor table initialization (including inheritance hierarchies) has been preformed. Mapped tenant discriminator columns are added automatically and we should avoid adding them more than once.

DefaultTableGenerator

Only a small change will be required to the DDL generator to ensure we capture a primary key setting for a tenant discriminator column. The following line will be added to the initTableSchema(ClassDescriptor) method: