From feba0bf949b71cfbddf1922c320661395cc1aa48 Mon Sep 17 00:00:00 2001 From: Steve Ebersole Date: Wed, 1 Feb 2012 12:22:06 -0600 Subject: [PATCH] HHH-7011 - Document multi-tenancy --- documentation/documentation.gradle | 13 ++++ .../chapters/multi-tenancy/Multi_Tenancy.xml | 65 +++++++++++++++---- 2 files changed, 67 insertions(+), 11 deletions(-) diff --git a/documentation/documentation.gradle b/documentation/documentation.gradle index 28053057aa..74bde4aaa8 100644 --- a/documentation/documentation.gradle +++ b/documentation/documentation.gradle @@ -37,6 +37,7 @@ jdocbook { } devguide { masterSourceDocumentName = 'Hibernate_Development_Guide.xml' + useRelativeImageUris = false } // todo : need to remove this once all content moved to devguide manual { @@ -45,6 +46,18 @@ jdocbook { } } +// todo : make this part of gradle-jdocbook. +// specifically the ability to supply ant-style resource for images (dir + include/exclude patterns) +stageStyles_devguide.doLast { + copy { + into project.file( 'target/docbook/stage/devguide/images' ) + from project.file( 'src/main/docbook/devguide/en-US' ) + include '**/images/*.png' + include '**/images/*.svg' + includeEmptyDirs = false + } +} + task buildTutorialZip(type: Zip) { destinationDir = file( "target/work/tutorials" ) archiveName = 'hibernate-tutorials.zip' diff --git a/documentation/src/main/docbook/devguide/en-US/chapters/multi-tenancy/Multi_Tenancy.xml b/documentation/src/main/docbook/devguide/en-US/chapters/multi-tenancy/Multi_Tenancy.xml index 621ed2f5be..6b3c5d2d81 100644 --- a/documentation/src/main/docbook/devguide/en-US/chapters/multi-tenancy/Multi_Tenancy.xml +++ b/documentation/src/main/docbook/devguide/en-US/chapters/multi-tenancy/Multi_Tenancy.xml @@ -21,34 +21,65 @@
Multi-tenant data approaches - There are 3 main approaches to isolating information in these multi-tenant systems. + There are 3 main approaches to isolating information in these multi-tenant systems which goes hand-in-hand + with different database schema definitions and JDBC setups.
Separate database + + + + + + + + + + - Each tenant's data is kept in a physically separate database instance. Generally an application - would define a JDBC Connection pool per tenant and select the pool based on the tenant of the currently - logged in user. + Each tenant's data is kept in a physically separate database instance. JDBC Connections would point + specifically to each database, so any pooling would be per-tenant. A general application approach + here would be to define a JDBC Connection pool per-tenant and to select the pool to use based on the + tenant identifier associated with the currently logged in user.
Separate schema + + + + + + + + + + - Each tenant's data is kept in a distinct database schema on a single database instance. An application - could choose to either: + Each tenant's data is kept in a distinct database schema on a single database instance. There are 2 + different ways to define JDBC Connections here: - use distinct JDBC Connection pool per tenant where the schema is part of the URL or - otherwise specified to the Connection pool + Connections could point specifically to each schema, as we saw with the + Separate database approach. This is an option provided that + the driver supports naming the default schema in the connection URL or if the + pooling mechanism supports naming a schema to use for its Connections. Using this + approach, we would have a distinct JDBC Connection pool per-tenant where the pool to use + would be selected based on the tenant identifier associated with the + currently logged in user. - use a single Connection pool but point the Connection to the correct schema based on the - tenant of currently logged in user based on ALTER SESSION command or similar + Connections could point to the database itself (using some default schema) but + the Connections would be altered using the SQL SET SCHEMA (or similar) + command. Using this approach, we would have a single JDBC Connection pool for use to + service all tenants, but before using the Connection it would be altered to reference + the schema named by the tenant identifier associated with the currently + logged in user. @@ -57,10 +88,22 @@
Partitioned (discriminator) data + + + + + + + + + + All data is kept in a single database schema. The data for each tenant is partitioned by the use of partition value or discriminator. The complexity of this discriminator might range from a simple - column value to a complex SQL formula. + column value to a complex SQL formula. Again, this approach would use a single Connection pool + to service all tenants. However, in this approach the application needs to alter each and every + SQL statement sent to the database to reference the tenant identifier discriminator.