Once upon a time, I was working on the assignment for the SCJD certification.
The project was a classic client-server application, with an RMI server, and a
Swing-based GUI, which you could use to book hotel rooms or some such. One of the
project requirements was to provide record locking, such that only one instance
of the client could edit the hotel room entry at once. Fairly standard stuff.
So, when the user clicks Edit Room in the client GUI, the client makes an RMI
acquireLock, and when that method returns, the client can then call
update, and so on. But if another client already has the lock, then the
acquireLock method will block until the lock becomes available. In that case,
the app shows a pleasant dialog like this:
Obviously you, as the user, would like to be able to click
And obviously you, as the developer, would like the RMI thread that’s stuck in
acquireLock method to return promptly. But you, as the developer,
would be sorely disappointed, because the RMI thread will continue to block.
Indefinitely! And from this outrage, thus was born the Interruptible RMI library.