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.
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.
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.
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]
