In the end, we just disagree on this one. You typically say don't rely
on ordering, because it may work some of the time, but it will always
bite you at the worst time. I think the same thing applies with
services. You shouldn't assume a service will always cleanly shut down;
rather, you should assume a service is always likely to throw an
exception, just like a remote reference. Then, if it does throw an
exception, try to find a replacement.
Perhaps you'd like this approach better if we had integrated
transactions. :-)
-> richard
Peter Kriens wrote:
The reason I object to INITIALIZATION ordering is that there is a very
good mechanism that can handle the underlying problem in a more
generic fashion: services. If these events become async, I am not sure
what will happen with that story.
Making the service events asynchronous will make this model a lot less
reliable because the window of vulnerability becomes larger. Lets face
it, both models suck, but I am not sure sync sucks more than async in
practice. Anyway, from my point of view as a user it is trivial to
turn a sync event into an async event. The other way around is
impossible. There are also some scenarios, like Device Access, that
will become impossible.
It would be interesting to get use cases for deadlocks caused by
synchronous events. Anybody on the list some horror stories? Maybe
there are some common patterns that can solve the problems.
Kind regards,
Peter Kriens
On 16 feb 2009, at 17:14, Richard S. Hall wrote:
For someone who preaches "no dependencies on ordering!", synchronous
events are just ordering in sheep's clothing. :-P
-> richard
Peter Kriens wrote:
I am not sure I fully agree. Though I do see the problems with
synchronous events I also see advantages. It is true that the
synchronous nature of external devices is not very relevant, but
most services are software based. In OSGi, services are often used
as dependency anchors. Treating these async, will make this less
reliable ... I think.
Interestingly, bundle events are async but a couple of years ago we
added synchronous bundle events because many people felt they were
needed. It is easy to blame what you know and idealize what you have
not ...
So I think it is not a black and white issue. Programmers should be
careful to use the synchronous events but I am not ready to declare
them all evil. It is easy to go from sync to async, vice versa is
impossible.
Kind regards,
Peter Kriens
On 13 feb 2009, at 21:51, Richard S. Hall wrote:
I agree this is the theory, but it (i.e., services blowing up when
you use them) is not something that can really be prevented.
Services can go away at any time, so you never know when you use
one if it will blow up, you have to treat them like remote
references and assume they always could blow up.
Further, just because the OSGi framework holds onto a
registration/reference/object does not give you any guarantees that
you can do anything graceful in a synchronous event. If the object
is the front-end to a bluetooth device and the devices was powered
off or went out of range, no amount of synchronicity by the
framework is going to stop the service object from blowing up when
you touch it.
Of course, people like the warm and fuzzy feeling that the
framework is providing them some guarantees. :-)
-> richard
Todor Boev wrote:
The synchronous event delivery is an attempt to make service
unregistration more graceful. This is the only way to provide an
'unregistering' event as opposed to 'unregistered'. E.g. when you
receive the event the service is still up and you can gracefully
stop using it. So before the call to "unregister()" returns there
is room for some final calls to your service as users get notified
and shut down.
If the service events were asynchronous the users of the service
would potentially blow up with an exception while attempting to
use it and only than receive an "unregistered" event. So the whole
point of the event goes down the drain - you want to know it's
going to go down before it does so you can avoid crashing with
exceptions right? At the same time the caller of "unregister()"
wants to know that when his call returns the service is no longer
used by no one and he can proceed to release the resources of the
service with no fear that someone will call in and mess something up.
Put all of these considerations together and it seems to me only a
synchronous unregistration event will work. And since the
unregistration must be synchronous it will be evil to make the
registration asynchronous don't you think? :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
