[
http://jira.amdatu.org/jira/browse/AMDATU-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans reassigned AMDATU-544:
---------------------------------------
Assignee: Bram de Kruijff (was: Marcel Offermans)
Please review the code and two extra tests. I will continue work on the design
and move that to its proper place (now in my sandbox).
> Add lifecycle methods for multi-tenancy.
> ----------------------------------------
>
> Key: AMDATU-544
> URL: http://jira.amdatu.org/jira/browse/AMDATU-544
> Project: Amdatu
> Issue Type: New Feature
> Components: Amdatu Core
> Reporter: Jan Willem Janssen
> Assignee: Bram de Kruijff
> Fix For: Sprint 4
>
>
> Add lifecycle methods/events for adding/removing a tenant from the container.
> Most of the time, multi-tenancy is handled transparently, but in some cases,
> you might want to write a bundle that explicitly controls how it behaves when
> there are multiple tenants in the framework.
> When the framework starts up, via some mechanism (we use a managed service
> factory so we can provide configuration for each tenant, but this mechanism
> can be implemented differently as well) a couple of Tenant services will
> appear, each with their own set of properties. If you want to support
> multi-tenancy, one thing you can do is listen for those services. However,
> the life cycle of an individual tenant can be longer than the life cycle of
> the framework: you might stop and start the framework and expect to still
> have the same set of tenants. If you were just listening to the Tenant
> service, you could be tricked into believing that if this service disappears,
> the tenant should go away. That is not very convenient if that means you
> start deleting data associated with the tenant, because you would like to
> preserve that so it's available the next time the framework starts again. On
> the other hand, never deleting the data means you cannot "garbage collect" it
> and you will have!
a "disk space leak". What would be ideal is some kind of mechanism of getting
notified whenever a tenant is created and destroyed. In our case, when the
configuration for that tenant is created or destroyed (but like I said, that
can be replaced by some other mechanism). The simple solution would be to send
an event when these things happen. However, if the event is sent while bundles
are still starting up, and your "listening" bundle is not started yet, it will
miss the event.
> The problem has a lot of similarities with listening for services. If you use
> a listener, you might miss things, so you need to combine that with some kind
> of lookup mechanism that gives you the "initial state" (from just before you
> started listening). Because this is non-trivial, OSGi created the
> ServiceTracker to make that easier to use. Later, they did something similar
> to track bundles: the BundleTracker. One suggestion would be to create
> something called a TenantTracker that could be used for this.
> The first step for this task is to come up with a design that demonstrates
> how you would solve this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://jira.amdatu.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
