Hi Kay, thanks for your answer. Arnulf Am Dienstag, 12. Juli 2005 09:50 schrieb Kay Ramme - Sun Germany - Hamburg: > Arnulf, > > Arnulf Wiedemann wrote: > > Hi Kay, > > thanks for the answer, that helps me partially. > > > > My detailed question is: > > I am sitting on the client side, the server is an ooo process with the > > urp/urtp bridge started on a socket. I query an Interface and get an > > object and a cache_index for the object back as well as as a type_class, > > type_cache index and interface_name for the type. After some method calls > > on that object, I don't need it any more. > > You don't get back any cache indexes for objects or types, except > potentially for the thread id. > in module bridges/remote/urp/urp_marshal.hxx function packOid there ist a call to packString( (void*)(&oid.pData) ) for the OID and a call to packInt16 (&nIndex), the latter is what I thought is the cache_index (same for types in packType) > > An Example: I query interface com.sun.star.uno.Xinterface and get back: > > oid: 24f56f548[gcc3];9f7e645555 > > object_cache_index: 1 > > type_class: INTERFACE > > type_cache_index:2 > > interface_name: com.sun.star.uno.XInterface > > > > Is it now correct to force a release call from the client with the > > object_id empty and the object_cache_index = 1, type_class = INTERAFCE > > and type_cache_index:2 > > to destroy the object 24f56f548[gcc3];9f7e645555 and the type cache entry > > for com.sun.star.uno.XInterface? > > If this is the first call > - on this object, you must send the OId, > - in this thread, you must send the thread Id, > - on this type, you must send the type. > yes understood, that is what I did. And if it is not the first call and I have used different objects in the meantime, I can send and empty oid with the appropriate cache_index. Is that correct? > It is certainly _OK_ to always provide all of the above info and to just > leave the caching out. If you want to utilize the cache, you need to > provide cache indexes for the different Ids and need to memorize the > usage of these indexes for reference/replacement on the client side. > ok, that is what I am doing. My question was: how do I tell the server to forget about the object (means to decrement the reference count for that object by 1). I thought that is done with the release call? > Kay > > > Arnulf > > > > Am Montag, 11. Juli 2005 17:37 schrieb Kay Ramme - Sun Germany - Hamburg: > >>Arnulf, > >> > >>life cycle for remote objects is in principal not different compared to > >>local objects. All UNO objects are reference counted. If the reference > >>drops to zero, the object destructs itself. > >> > >>During a remote calls, objects become passed to the other processes. We > >>only need to differentiate between > >>-1- objects as results > >>-2- objects as parameters for synchronous calls > >>-3- objects as parameters for asynchronous (oneway) calls > >> > >>-1-: If a method returns an object, the callee must acquire the object > >>before passing it back. If such a method becomes called asynchronously, > >>the object must be released by the bridge. > >> > >>-2-: The object passed must already be acquired. The caller needs to > >>acquire the object only, if it somehow copies a reference. > >> > >>-3-: The calling bridge must acquire the object before sending the call. > >>The remote bridge must send a release call, after the asynchronous call > >>has been executed. > >> > >>If I remember correctly, the current implementations acquire passed > >>objects before every call and pass release calls for these as in -3-, > >>mainly for simplicity reasons. This is not as worse as it sounds, > >>because release calls A) get accumulated and send as a burst, and B) are > >>asynchronous anyway. > >> > >>Remote bridges are reference counted as well and automatically destruct > >>themselves at the moment the last mapped object gets unmapped, allowing > >>transparent breakup of remote connections. > >> > >> > >>Hope that helps > >> > >>Kay > >> > >>Arnulf Wiedemann wrote: > >>>Hi, > >>>I am looking for detailed information on what is happening, if I send a > >>>release call to the urp bridge. Especially how do I release local and > >>>remote objects and types (do I just set the appropriate header flags and > >>>put the type and/or object info into the message body, do I have to > >>>release the remote types/objects at all?) and how can I be sure that the > >>>desired release has worked, as the release call is a one_way call. Any > >>>info or link to docu is appreciated. > >>>Arnulf > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
