Re: Object-identity and lifecycle in the CORBA-UNO bridge

[Joerg Budischewski <joerg budischewski germany sun com>]

> > B) ONEWAY CALLS
> > - Does ORBIT guarantee the sequence of oneway calls ( this meeans is it
> > guaranteed that successive oneway calls on an object reach the callee in
> > the order the caller sent them. The CORBA specification explicitly denies
> > this. ).
> ORBit (and all other ORBs AFAIK) do not make any effort to de-order the
> requests for any type of call, so things will naturally arrive in order.
The problem starts in general, when you have a multithreaded server. If 
the server does not care for something like thread identity, calls may 
overtake or (if they process longer) arrive simultanously.


> > C) OBJECT LIFETIME
> > - For the GNOME::Unknown interface, is there any special treatment in the
> > ORBIT runtime ?
> No.

> > - Is there a different treatment for oneway calls, that pass on object
> > reference ?
> No.
If you do reference counting COM-like, I see a problem with that, if you 
have e.g. the following code :
Unknown A = createMyUnknown();
B->call( A );
A->unref();

This code will in general not work when call() is a oneway method, 
because A may be get destructed before the call arrives at the callee. 
COM can cope with that, because the underlying infrastructure can keep 
the object acquired.

> This would consist of UNO implementing the OAF::ObjectDirectory interface
> itself to provide a list of and activation for all the available UNO
> objects, and hooking that OD into the main OAF::ActivationContext used by
> the user.  That seems like a very clean and passable solution from what I
> know. You will need to ask Maciej for details on how hard this might be,
> since he is the OAF guru now.
Yes, you mean to implement it in CORBA as a shared-library-component. 
Good idea. I would be able to start the office with command-line 
parameters, that the office is used to and yet do not need another an own 
daemon process.

Greetings, Joerg