On 6/14/09 5:08 PM, Todor Boev wrote:
Some say we should never call out from the bundle while holding a lock but I think we are safe if we use a dedicated private lock for every tracked service. In any case I can't think of any other way to be safe at all times. Lately however I have been encountering the "local-cache" approach, which seems to state we don't need to be that paranoid. E.g.void usefulMethod() { Hello service = get(); /* At this spot right here the service can go down! */ service.greet("World"); } Here we risk calling a service in an undetermined state. Do we expect every exporter to invalidate his objects to keep us safe? E.g. the exporter must keep a "closed" flag around, mark the service as invalid in a thread-safe manner, and start tossing exceptions at callers from that point on. iPojo follows the local cache approach - right Richard?
Yes. iPOJO is of the philosophy that service departures will likely lead to errors, so you are better off being prepared to catch them and fail gracefully, sort of like errors in distributed computing. Even if you hold a dedicated lock, there is no guarantee that calling a method on the service object won't throw an exception. Locks don't stop the service from going away (think bluetooth device), in some cases if it goes away it is gone, period.
Given that you have to deal with this case anyway, you might as well just treat all services the same way rather than trying to figure which is which case. This will become even more complicated as people start using distributed services from R4.2.
But depending on your application and what control you have over everything, then either approach is fine.
-> richard
Peaberry follows the dedicated lock approach - right Stuart? I'd be grateful if you help me compare these import modes. That is if I got it right who uses what :) Cheers, Todor --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
