[
https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842745#action_12842745
]
Marc Morin commented on OFBIZ-3540:
-----------------------------------
>From the experience of our multi-tenant implementation, we've noticed
- multi-tenant was easy to add for the base case, as this patch indicates, the
delegator pretty much abstracted much of it away.
- we more formally, expanded the entity-engine.xml definition to define ftl
templates for the tenant databases configuration. When looking up a tenant's
db configuration, we set the hostname, username, password, tenantId, etc in a
context that is applied to generate the tenant's specific configuration. This
allows for changing the sequenced-id-prefix for each tenant, allowing "easier"
merging of data between tenants. We chose to use entirely different
delegatorNames, such as 10000, 10001, etc.... directly from the
SequenceValueItem.
- The EntityCache is per delegator, and not per unique datasource, we haven't
changed this, but it essentially, prevents sharing the same datasource amongst
tenants
- Selecting the delegator/tenant is needed in different areas of the
application, via different techniques. via explicity selection, as the login
demo application here, but we've also need to associate the "hostname" of the
HTTP request, to enable multiple entire instances, both authenticated and not,
to be distinguishable.
- The dispatcher will create a seperate job manager for each "tenant". This is
fine for a small number of tenants, but with a larger number, a single
JobPoller/Manager is required. We've added these enhancements and additional
tenantId field on the JobSandbox. We interpret, "null" in tenantId, here to
mean, replicate this job to run all all tenant instances. Think of all the
"cleanup" jobs, etc...
- Singleton JobManager also handles scheduling of jobs for tenants that haven't
been "loaded"... The current mechanism will not load the tenant, until someone
logs in that instance.
- The life cycle, create, upgrade, decommission of the tenants is a non trivial
amount of work. We've spent a large amount of effort here, to keep the support
cost down for 1000's of tenants in a system. Creating a new tenant from a
"blank" template, applying upgrade sql files, etc...
- Since our service is a subscription, we modeled the tenant instance as a
Product in our master instance. We use the Subscription product behavior to
help control the expiration, etc.. of the tenant.
Many of these changes are in our forked version of the code. We can try to
extract components that people feel would be beneficial if there is interest.
> Multi-Tenant Support (Login Based)
> ----------------------------------
>
> Key: OFBIZ-3540
> URL: https://issues.apache.org/jira/browse/OFBIZ-3540
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
> Affects Versions: SVN trunk
> Reporter: David E. Jones
> Assignee: David E. Jones
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: MultiTenant20100305.patch, MultiTenant20100305.patch,
> MultiTenant20100305.patch
>
>
> Support multiple tenants in a single instance of OFBiz. Each tenant will have
> its own databases (one for each entity group). Database settings will
> override the settings on the delegator with parameters from an entity record
> so that new tenants can be added on the fly without restarting the server
> (new tenants will still need to have data loaded in their databases just like
> any other).
> If valid Tenant ID is specified when user logs in then webapp context will be
> setup with tools for that tenant as a variation of the base delegator
> (including delegator, dispatcher, security, authz, visit, server hit, etc
> handled for it).
> Demo data includes a couple of sample tenants. After loading demo data (ant
> run-install) try logging in to webtools or any other admin app with the
> Tenant ID of "DEMO1".
> NOTE: this patch also addresses some stability issues with the LoginWorker,
> ControlServlet, Visit, and ServerHit functionality that was exposed while
> developing this. For example, after a logout functionality that runs in the
> ControlServlet may fail because things that were in the session before are
> not there any more. In this patch there is code to rebuild the request and
> session after logout (necessary for changing tenants, helpful for these other
> issues).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
