[ome-devel] session->closeOnDestroy() not closing session

Bernhard Holländer bernhard.hollaender at gmail.com
Wed May 6 11:46:46 BST 2009


Hi Josh!

Thanks again for the detailed answer :-)

>  > Maybe I do not understand the purpose of
>  > ServiceFactoryPrx::colseOnDestroy, but when I do the following:
>
> closeOnDestroy & detachOnDestroy are counterparts used to toggle a
> flag within your server-side OMERO session, but do not actually
> perform any actions. The default value for the flag is
> "closeOnDestroy" which means that if client.closeSession() or
> serviceFactoryPrx.destroy() is called, or the Glacier2 session times
> out (which ultimately calls serviceFactoryPrx.destroy()) then the
> OMERO session is also closed.
>
> This is the standard usage. If you need to share a session between
> multiple clients, or to keep it alive between client restarts, then it
> is necessary to call detachOnDestroy(), which initiates reference
> counting for the session. I need to add a self-contained example of
> this. If you (or anyone on the list) has a pressing need, please let
> me know.

Not needed at the moment. Just one question, is there a timeout for
the OMERO session like for the Glacier2 session?

>
>  > try {
>  >     session_->ice_ping();
>
> ice_ping() will keep the Glacier2 session alive, but will not keep
> your OMERO session alive. For that, use sf.keepAlive()

Related to the question above: could it be that the OMERO session
times out before the Glacier2 session? If this is not the case, there
is no need for me to call keepAlive on the ServiceFactoryPrx since it
will be destroyed and recreated if the Glacier session timed out.

However, when implementing a ping thread as suggested in the
Ice-manual, would it not be sufficient to call sf->ice_ping()? Would
one need to call sf->keepAlive in the same thread every now and then?

Thanks for your help! Bernhard


More information about the ome-devel mailing list