[omniORB] Any way to differentiate clients with omniORB

BaileyK at schneider.com BaileyK at schneider.com
Wed Apr 16 09:19:37 BST 2008


Yes, #2 would create multiple CORBA objects.  Mapping them all to the same
servant can be done in a number of ways.  You could use the
USE_DEFAULT_SERVANT request processing policy when creating a child POA.
Then have a factory object in the root poa which bootstraps the clients by
assigning a distinct ObjectID to each client and creating an object
reference using the child POA and ObjectID.  The default servant can use
POACurrent to access the ObjectID.  This is similar to the way a session
cookie works for a web browser.

You can also use a ServantLocator, and examine the ObjectID in the
preinvoke() call.  I don't know which is more efficient.

It's been some time since I've used this stuff, so I may be wrong on some
details.  If you don't have the Henning/Vinoski book, you should probably
get it.

There's all kinds of fun stuff you can do once you start to use child POAs,
servant managers, and ForwardRequests.  I built a custom load
balancer/fail-over/implementation repository service with OmniOrbPy a few
years ago.  It's been working flawlessly ever since.

---
Kendall Bailey
Engineering & Research

Martin Trappel <0xCDCDCDCD at gmx.at> wrote on 04/16/2008 01:26:48 AM:

> BaileyK at schneider.com wrote:
> > 2) If sharing servant state across clients is necessary, use a single
> >
>
> Thanks for these pointers!
>
> Option 2 sounds quite promising ... would this conceptually create 2
> CORBA Objects supported by one servant, or would it still be one CORBA
> Object that only is registered twice? (What would _is_equivalent(..)
> tell me?) Also, at the moment I'm just running the default POA with the
> default policies (omni 4.1.2) ... I guess I'll have to do something
> there too?
>
> ... anyways I'll follow your link and try it out from there ...
>
> br,
> Martin




More information about the omniORB-list mailing list