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.
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?
Assuming that the tuple <"24f56f548[gcc3];9f7e645555",
com.sun.star.uno.XInterface> was not _bridged in_ (see urp.html) at the
server side at the time the server sent back the reply message
corresponding to the queryInterface: The client is bound to eventually
send a release request for OID "24f56f548[gcc3];9f7e645555" and type
com.sun.star.uno.XInterface. However, there are independent caches for
both directions of an URP bridge, so in general any cache indices for
one direction (server--client) will not work for the other direction
(client--server). (Just construct the release request message as you
would construct any other request message.)
The effect of this release request is only on the reference count for
the tuple <"24f56f548[gcc3];9f7e645555", com.sun.star.uno.XInterface> on
the server side. It does not remove any information from the type cache
or OID cache. Whether and when any object is "destroyed" at the server
side is not discernible from the client side (apart from the fact that
the object with OID "24f56f548[gcc3];9f7e645555" is guaranteed to remain
in state _active_ (lifecycle.html) as long as the release request has
not been sent).
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]
