[
http://jira.amdatu.org/jira/browse/AMDATU-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697#comment-12697
]
Bram de Kruijff commented on AMDATU-544:
----------------------------------------
{quote}
What I am doing is making sure that a bundle that has a certain binding, only
gets (in this case) BundleDataStore services for the tenants its bound to.
Especially if you have a lot of bundles with "platform" binding, and a lot of
tenants, that will save you a lot of services in the registry. So I am not
introducing any new use cases here, just implementing what we already came up
with.
{quote}
I'm not sure about this... (*confused*)
Please explain this for the initial "BigData" case. Roughly the requirements
here is that there is one ("singleton") cassandra application service. It will
have Binding = PLATFORM. However, this service must create/drop table spaces
when tenants are created and dropped. Hence, there is no 1-1 mapping of the
component scope and its tenant lifecycle interest. How does this work in the
current setup?
Moreover, I'd say that typically only components in the PLATFORM scope are
interested in only TENANTS. At present tenant factory (which has a global
scope) will pickup all listeners and give them callbacks. This allows tenant X
to see event with regard to tenant Y.
{quote}
The integer for the scope property is not a magic number but a bit set.... If
you only use multi tenancy, you don't have to even know this exists, so it's
not a concern unless you start implementing your own multi-tenant storage
solutions.
{quote}
I was referring to the 1, 2 & 3 in
MultiTenantBundleActivator.getScopeBitfield(). If, a developer needs to be able
to register it's custom listener that should be public constants.
{quote}
I could have used java.util.BitSet which might have actually prevented the bug
you found (I should have "and"ed the two, not "or"ed them to test if a bit was
set). I used the bit set (and some other things) to indeed improve performance.
{quote}
The facts that 1) you made an error implementing it, 2) it took me 10 minutes
to comprehend it and work out the bug and 3) I do not believe that it makes any
significant performance diff over using string constants... makes me argue that
this is premature optimization.
> 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
