[omniORB] Getting ObjectId when using default servant

[Chris Newbold]

Date: Mon, 04 Dec 2000 11:48:21 +0000
From: Duncan Grisby <dgrisby@uk.research.att.com>

> On Sunday 3 December, randy.shoup@tumbleweed.com wrote:
>
> > What are the plans for adding support for PortableServer::Current in
> > omniORB3?  What are the technical barriers, if any, to implementing
> > this?  In my naivete, it seems to me that it is just a matter of taking
> > advantage of thread-local storage to store the current POA and object-id
> > during an operation invocation :-).
>
> It's almost as simple as doing that. The main barrier to it being
> added to omniORB 3.0 is that the omnithread interface has no
> thread-local storage facilities, so there is no way to do it. Once

We're also interested in default servant support. In the mean time,
I've come up with a relatively clean way to fake this. My main
concern is that there will be a lot of default servant code and we'd
like to write it according to the standards and not have to fiddle
with it later. Performance is less of an issue in this particular
application.

What we're going to do is have a ServantLocator implementation which
grabs the ObjectId in preinvoke and stashes it in thread-local storage
(using pthreads). Then we have our own PortableServer::Current
implementation to access the value (this is trival).

Instead of configuring the POA for a default servant, we install this
ServantLocator. The ServantLocator always returns the default servant
from preinvoke.

There are only two things we'll need to change once omniOrb has official
support: the way we get PortableServer::Current and the POA configuration.

-Chris Newbold
Laurel Networks