[
http://jira.amdatu.org/jira/browse/AMDATU-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725#comment-12725
]
Marcel Offermans commented on AMDATU-544:
-----------------------------------------
1) Agreed that that's a better place for them, so they have been moved.
3) Changed the wording a bit, see below.
4) Will work on that next...
Trying to summarize our discussion: You see these life cycle notifications as
asynchronous events, whilst I modeled them as a whiteboard style listener.
In your case, we should get rid of our interface completely and use EventAdmin
in which case we can fire them asynchronously and have them delivered using
multiple threads (depending on the implementation of EventAdmin). My choice is
to use the whiteboard pattern, not start extra threads and directly invoke the
methods. To me, this is no more dangerous than allowing a whiteboard style
Servlet to directly highjack a thread and bring down the whole platform by
slowly consuming the whole thread pool of the web server.
I'm fine with discussing this further, I don't think it warrants delaying our
release. This API only affects developers that implement custom multi tenancy
strategies that involve persistency. To me, this is a different group of people
than our application developers, but even those should know what they're doing.
I mean, we are not in the business of providing sandboxes that provide
bulletproof environments where developers cannot do anything wrong. That's just
not possible in Java at all.
> 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
