Re: Problem with getting current POA

[Philip Lijnzaad <lijnzaad ebi ac uk>]

Andrew> I'm using ORBit 0.5.5 and PortableServer_Current_get_POA() and
Andrew> PortableServer_Current_get_object_id() are both unimplemented, but
Andrew> appear to be important for managing objects using a default servant for
Andrew> a class.

that's right.

Andrew> Alternatively, can anyone suggest a different way to do what we need?

I agree with your further post; I would really like to see ORBit support the
full POA, including DefaultServant and the Current interface needed for
it. E.g. if you want to do anything really fancy with ORB/database
integration, this feature is essential.

If you are willing to work around things, however, you could use a
ServantLocator in which preinvoke() always returns the exactly the same
servant, but with oid, poa (and possibly operation) set to the values passed
to preinvoke(). This way, you don't ask Current for the object_id and POA,
but it is available from the servant.  (I must admit I don't know if there
are any issues with thread safety, though). Oh and for good measure, make
sure postinvoke() deletes any superfluous state on the servant, if there is
any (and in fact there shouldn't be ...). E.g., to aid debugging, oid and poa
etc. can be set to NULL after use.

It may, BTW, be that the reason for not adding the Current interface to ORBit
is exactly because of this relatively clean work-around.

Andrew> This is important to the GNUe project, because our object server needs
Andrew> to manage references to large numbers of objects, not all of which
Andrew> should have to be in memory at a particular time, as they can be
Andrew> retrieved from a database on demand.

'not all of which' sounds different from 'none of which' :-). DefaultServant
is intended for the latter, ServantManager (-Locator or -Activator) for the
former (which is better implemented using an evictor, probably using
ServantLocator). I.e., it may well be beneficial to have a little 'cache' of
servants, which is managed a ServantManager. But it depends on the
transactional properties of the system. If all access goes through the same
CORBA server, you can be sure that your cache is always consistent with the
database state, and in that case I would suggest a ServantManager + evictor. 

If changes to the persistent state of the objects happen 'behind the CORBA
server's back', then DefaultServant (or the work-around) is essential. 


Cheers,
                                                                      Philip

-- 
C++: The power, elegance and simplicity of a hand grenade. (Kenneth C. Dyke)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijnzaad ebi ac uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639                 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           \ Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53