[en] Event semantics (solved)

Topics: Technical Support
Coordinator
Feb 23, 2012 at 6:23 PM
Edited Feb 25, 2012 at 2:23 PM

Hi Rainbird,

In the present version of Zyan there is a huge difference in event semantics of singleton and single-call components. Singlecall events can only be wired-up to event handlers of the same client which is making the remote call, whereas singleton events work as expected (i.e., can be handled by any client). This difference in event semantics is a bad thing: the client should be aware of the component activation type to make a proper use of events. It's bad because activation type is something like component configuration details and thus should only be known to the server. It's even worse because it forces to create singletons every time we need some global notifications.

As far as I can see, this is mainly due to the technical reasons. I. e., wiring up all event handlers to a single-call component may take a lot of time. And it should be done before every single call, so the call becomes very expensive. Am I right?

If the answer is yes (no architectural/ideological reasons for different event semantics), then we should probably fix this. I'm sure it can be done :)

Coordinator
Feb 27, 2012 at 7:25 PM

Hi yallie,

sorry for my late response.

I see no architectural or ideological reasons why event subscription lifetime of SingleCall components should be limited to a single call. Events generally have negative impact on scalability (I think of Network Load Balancing and such stuff). But when someone is using remote events, he must swallow this pill.

One approach to fix the SingleCall event semantics could be caching event subscriptions. When a client subscribes to an server event, ZyanDispatcher creates a stub object which holds all the client subscriptions. Every SingleCall instance must be wired to this event stub. This is easier and should be cheaper than creating wires to all the client instances on every call.

Events of SingleCall components would behave like Singleton components. But CancelEventHandler events and similar ones may be tricky.

Coordinator
Feb 27, 2012 at 11:03 PM
Edited Feb 27, 2012 at 11:13 PM

>When a client subscribes to an server event, ZyanDispatcher creates a stub object which holds all the client subscriptions.

Yes, exactly!

I also think that we should further improve DynamicEventWireBase and replace delegate invocation list with something more intelligent. Every event should hold some custom list of handlers to enable parallel processing, sorting, optional asynchronous invocation, etc. We should also not forget to add some EventInvocationFailed event suggested by Bernd (radio42 user).

>But CancelEventHandler events and similar ones may be tricky.

I don't feel that distributed event model should at all support things like this... Even if it's possible, it would introduce race conditions (CancelEventArgs will be sensitive to the client subscription order, so clients will interfere with one another, event fired in parallel will have to share single EventArg instance and provide synchronized access to it, et cetera). Therefore I think that distributed event arguments should always be treated as read-only messages that can only be passed in one direction — from the server to a client.

Coordinator
Mar 4, 2012 at 10:14 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.