Re: What is the correct service import behavior?
nope - peaberry doesn't hold any locks during the actual service call, it only has a small amount of synchronization to properly manage internal records when setting up and tearing down a service call Yup. I figured that would be the case after Richard's replay. Now the lock holding mode does not make much sense to me either :) Todor - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: What is the correct service import behavior?
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
Re: What is the correct service import behavior?
Richard S. Hall wrote: 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. I completely agree. This is all about crashing safely, not trying to avoid crashes with synchronization. Crashing safely means we always get an exception when trying to access a missing service. If we allow some final calls to an unregistered service object we risk getting random return values and other behavior that can corrupt the importing bundle. Here the question is if we should count on the exporter to place extra invalidation code in his service object so it consistently throws exceptions at late retainers? Or should we take matters in our own hands and guarantee a ServiceUnavailableException will always be thrown from our own internal tracking code? Todor - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: What is the correct service import behavior?
Todor Boev wrote: Richard S. Hall wrote: 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. Ah..I get it! You mean we should not bother to block the unexport of the service when the framework calls into our ServiceListener because that won't keep the service functional until our last calls to it return. Come to think of a service can throw an exception due to a missing transitive dependency anyway. Seems I am still not completely free from that safe mentality :P Seems in the end we should count on the service exporter to toss exceptions at us rather than do random nastiness out of a partially destroyed service. Todor - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
