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

[josh.moore at gmx.de]

Bernhard Holländer writes:
 > Hi developers!

Tag, Bernhard.

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

 > 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()

 > } catch (const Ice::ConnectionLostException& e) {
 >     // recreate session
 >     session_ = client_->createSession(username_, password_);
 >     session_->closeOnDestroy();
 > }

 > I need to call client_->closeSession() before I can create it again,
 > otherwise I get a client error. I thought the closeOnDestroy does the
 > session closing action automatically.

closeSession() is required due to a quirk in the Ice runtime which
does not allow re-using a communicator after a Glacier2 session is
closed[1]. To prevent future issues if this is ever fixed, it's
cleanest to require a closeSession().

 > By the way, the call to client_->closeSession() was not required in omero3.1.

In general, 4.x takes lengths to be safer and more correct.

 > Thanks! Bernhard

Cheers,
~Josh

[1] http://www.zeroc.com/forums/help-center/1911-how-re-establish-glacier2-session-after-connection-explicitly-closed.html