Archived

This forum has been archived. Please start a new discussion on GitHub.

Contexts and threads

It is my understanding from skimming the documentation that in ICE you have two choices when using contexts:

1) explicit on each call
2) create a new "proxy" with embedded context, which is implicitly passed on each call

I am interested to know how to pass a unique context implicitly, in a multithreaded environment. For example, say I am running in a middle tier environment, like a servlet engine, serving many end users. Each of my threads has to pass on implicit context object identifying the end user (which will be different for each thread).

One (the only?) solution is to create a new proxy with embedded context for each thread. Is this feasible with regard to performance? Is creating these proxies cheap and side-effect free? Is there any other mechanism by which I can associate context by _thread_ and not by _proxy_ (for instance, let's say I want to use the same context for many types of proxies - any that I talk to during a given transaction).

Lastly, is there an IRC channel somewhere that I can talk directly to people using/working on ICE?

Comments

  • marc
    marc Florida
    First of all, I'm not sure if you are using contexts for what they are intended. Contexts should contain information about a requests, such as routing information. A user id should be a regular parameter, not be embedded in the context.

    In any case, creating proxies is cheap, client-side only, and free of side effects. We don't use thread-specific data for contexts, because it's simpler and more efficient to simply create a proxy with a new default context.

    ZeroC does not maintain an IRC channel. For such a level of support, you would need a consulting contract with us.
  • Thanks for the reply, that answers my question. The example I gave you was simplified. The case in which we do this is propagating multiple tiers of authentication in a single-signon scheme, which if we had to do in an explicit manner would horribly litter method signatures with extra (rather opaque) parameters that are of little interest directly to application developers. For example we have implemented hooks/frameworks for doing such in CORBA and also recently SOAP, so I was just curious about ICE (we are not using ICE at the moment, but I discovered it is a charming protocol so I thought I'd ask ;) )