This forum has been archived. Please start a new discussion on GitHub.

UserException in Servant

My apologies in advance if this is a FAQ.

Assume we have an employee database interface that creates a new employee and returns its proxy to the caller. When the client's call is dispatched in the server, our servant creates a database entry for the new employee and returns its proxy. If a subsequent error occurs on the server's connection with the client which prevents the Ice runtime from sending the function result (i.e., the employee proxy) back to the caller, I'd like a programmatic means of "undoing" the servant's actions - i.e., removing the newly created employee entry - in order to preserve database integrity. Since the client's call will ultimately fail with an exception (e.g., ConnectionTimeout), no new employee database record should persist.

Unless I'm mistaken, servants don't appear to be "notified" of such exceptional conditions. Does anyone know how this kind of issue is typically addressed in distributed systems implemented with Ice?

Thanks in advance for your help,


  • Re: UserException in Servant

    Oops, my apologies for the thread title. As you can see from my post, I'm not talking about a UserException; rather, I'm talking about some kind of Ice LocalException that might occur after the client's invocation has completed in the servant but before the result has been sent back to the client.

    Sorry for the confusion.

  • matthew
    matthew NL, Canada
    This is not an Ice specific problem, it is instead a problem that in any distributed system must be solved. A notification, as you suggest, of failure from Ice to the server (even if it were possible) would not really help matters as failure can occur at a higher level

    There are multiple solutions to this type of problem. Here are a couple:

    One is to use some sort of two-phase commit protocol (such as a transaction service). The client starts a transaction, creates whatever objects are necessary and then commits the transaction. A failure in the client results in the transaction being rolled back.

    Another solution is to use some sort of session mechanism. The client creates a session with server, which is pinged on a regular basis. If the client fails to ping the session, the server tears down the session and cleans up all data associated with the session. Take a look at demo/Ice/session for an example.
  • You might also want to read the article "The Grim Reaper: Making Objects Meet Their Maker" in Issue 3 of our newsletter Connections. This article describes how to get rid of objects that have been abandoned by clients.