[
http://jira.amdatu.org/jira/browse/AMDATU-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699#comment-12699
]
Bram de Kruijff commented on AMDATU-544:
----------------------------------------
{quote}
The second, multi-tenant aware, but with a custom implementation, will not use
our bundle activator wrapper, because it wants to do something special.
Therefore I don't see it having any binding in the manifest (or if it does,
just to indicate its intention). Its implementation will publish the
TenantLifeCycleListener with binding "tenants".
{quote}
Aha, ok now I get it. The automagic mapping that confused me was the code in
MultiTenantBundleActivator for binding the MultiTenantBundleDataStore. Makes
sense and yes "BigData use-case can simple have adapter binding "PLATFORM" and
then register the TenantLifeCycleListener with binding "TENANTS". Tested and
works!
{quote}
Regarding the bitfield, I agree we should add constants. As for the premature
optimization, that is debatable.
{quote}
No it's not cause I'm not gonna debate it. If you want to show of your coding
skills by optimizing away -micro-nanoseconds in a non performance critical area
be my guest ;) Let's just get the constants in.
Still curious about why you have chosen to implement this using sync callbacks?
As they are all post events I think this could easily be async making it more
scalable and manageable?
Summarizing the TODO is;
1) Add lifecyclelistener binding constants
2) Extend itest to cover the new binding feature
3) Complete javadoc on API and classes
4) Update wiki documentation on usage
> 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 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
