Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

HHH-7011 - Document multi-tenancy

This commit is contained in:
Steve Ebersole 2012-02-01 12:22:06 -06:00
parent 8bead4f084
commit feba0bf949
2 changed files with 67 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
documentation/documentation.gradle
View File

@ -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'

65
documentation/src/main/docbook/devguide/en-US/chapters/multi-tenancy/Multi_Tenancy.xml
View File

@ -21,34 +21,65 @@
<section>
<title>Multi-tenant data approaches</title>
<para>
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.
</para>
<section>
<title>Separate database</title>
<mediaobject>
<imageobject role="html">
<imagedata fileref="images/multitenacy_database.png" format="PNG" align="center" />
</imageobject>
<imageobject role="fo">
<imagedata fileref="images/multitenacy_database.svg" format="SVG" align="center" width="17cm" />
</imageobject>
</mediaobject>
<para>
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
<quote>tenant identifier</quote> associated with the currently logged in user.
</para>
</section>
<section>
<title>Separate schema</title>
<mediaobject>
<imageobject role="html">
<imagedata fileref="images/multitenacy_schema.png" format="PNG" align="center" />
</imageobject>
<imageobject role="fo">
<imagedata fileref="images/multitenacy_schema.svg" format="SVG" align="center" width="17cm" />
</imageobject>
</mediaobject>
<para>
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:
<itemizedlist>
<listitem>
<para>
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
<literal>Separate database</literal> 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 <quote>tenant identifier</quote> associated with the
currently logged in user.
</para>
</listitem>
<listitem>
<para>
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 <literal>SET SCHEMA</literal> (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 <quote>tenant identifier</quote> associated with the currently
logged in user.
</para>
</listitem>
</itemizedlist>
@ -57,10 +88,22 @@
<section>
<title>Partitioned (discriminator) data</title>
<mediaobject>
<imageobject role="html">
<imagedata fileref="images/multitenacy_discriminator.png" format="PNG" align="center" />
</imageobject>
<imageobject role="fo">
<imagedata fileref="images/multitenacy_discriminator.svg" format="SVG" align="center" width="17cm" />
</imageobject>
</mediaobject>
<para>
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 <quote>tenant identifier</quote> discriminator.
</para>
</section>
</section>