[
http://jira.amdatu.org/jira/browse/AMDATU-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bram de Kruijff reopened AMDATU-544:
------------------------------------
Assignee: Marcel Offermans (was: Bram de Kruijff)
Some comments & questions, cause I'm not exactly clear what the scoping is all
about.
Judging from the code in MultiTenantBundleActivator a "PLATFORM" results in a
scope field 1. The TenantServiceFactory seems to (try) and filter that to only
invoke it when the "PLATFORM" tenant disappears.. or the inverse? Not sure if I
understand it correctly.. does it cover a use case where a "singleton" platform
scoped services must monitor tenants?
My question above may have to do with the fact that I can not find any
documentation on the design or use cases. I guess you must document this under
the multi-tenancy design.
I'm also not sure if the usage of an Integer for the scope property, magic
numbers in the implementation are a good idea. Any developer implementing a
listener would have to set this correctly, right? In that case at the very
least they should be public constants. Also wondering if this complex solution
provides a real performance benifit over just using the existing
{PLATFORM,TENANT,BOTH} constants?
Finally, I think the mechanism doesn't work at the moment. The bitwise compares
in TenantServiceFactory will always be true, adding all listeners to both maps.
My ad hoc itest below seems to confirm this as it gets the same callbacks no
matter what value I set.
{code}
@Test
public void testTenantLifeScopeCycle() throws Exception {
Listener initialListener = new Listener(){
public void initial(String[] tenantPids) {
super.initial(tenantPids);
StringBuilder sb = new StringBuilder();
for (String pid : tenantPids) {
sb.append(" " + pid);
}
System.err.println("Lifecycle: delete: " + sb.toString());
}
public void create(String tenantPid) {
super.create(tenantPid);
System.err.println("Lifecycle: create: " + tenantPid);
}
public void delete(String tenantPid) {
super.create(tenantPid);
System.err.println("Lifecycle: delete: " + tenantPid);
}
};
DependencyManager dm = m_testContext.getDependencyManager();
Dictionary<String, Object> props = new Hashtable<String, Object>();
props.put(org.amdatu.tenant.adapter.Constants.MULTITENANT_LIFECYCLELISTENER_BINDING_KEY,
Integer.valueOf("1"));
dm.add(dm.createComponent()
.setInterface(TenantLifeCycleListener.class.getName(), props)
.setImplementation(initialListener));
String pid1 = generateTenantPID();
Configuration tc1 = addTenantConfig(createTenantConfiguration(pid1));
removeTenantConfig(tc1);
}
{code}
> 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: Marcel Offermans
> Fix For: Sprint 5
>
>
> 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
