Thread safe RMI

Question

Thread safe RMI.
My RMI server provides clients with the ability to CRUD data but in order to manage concurrency I did the following.
1stly I would like to understand correctly the issues of RMI server objects....
It is my understanding that RMI server can cater for eg 100 clients by spawning 100 threads at random for each client. This process is not managed (thread wise) and the result is that 20 clients wishing to update record A can do so at will? Various steps can be taken from what I gather...
a) Synchronise (expensive)
b) implement a lock manager.
The step I have taken is include a lock manager and I have ensured that all locking an unlocking occur in a singleton server object that manages all sensitive data CRUD operations. Now I use a lock manager but I would like to know what happens if for eg the 1st RMI client dies and has its thread blocking
all other threads from locking the same record? Does the thread die with the client or is there a counter measure for this? The obvious answer that comes to mind is Object.wait() inside the lock manager?
The reason I ask was that because all of the locking occurs in a single method call in the Network
Server's JVM, so is there a need to worry about the RMI connection dying during the middle the locking operation.
Edited by: Yucca on May 23, 2009 8:14 PM/*
* @(#)LockManager.java
* Version 1.0.0
* 27/03/2009
import java.util.HashMap;
import java.util.Map;
import java.util.logging.Logger;
import java.util.ResourceBundle;
class LockManager {
     * The <code>Map</code> containing all the record number keys of currently
     * locked records that pair with the cookie value assigned to them when they
     * are initially locked.
    private static Map<Integer, Long> currentlyLockedMap =
            new HashMap<Integer, Long>();
    private static final Logger LOG = Logger.getLogger("project.db");
     * Locks a record so that it can only be updated or deleted by this client.
     * Returned value is a <code>long</code> that is the cookie value that must
     * be used when the record is unlocked, updated, or deleted.
     * If the specified record is already locked by a different client, then the
     * current thread gives up the CPU and consumes no CPU cycles until the
     * record is unlocked.
     * @param   recNo                   the assigned primary key of the record
     *                                  to be locked for an operation.
     * @param   data                    a <code>Data</code> instance used to
     *                                  check if the record exists before
     *                                  attempting the lock operation.
     * @return                          A <code>long</code> containing the
     *                                  cookie value that must be used when the
     *                                  record is unlocked.
     * @throws  RecordNotFoundException if specified record does not exist or if
     *                                  specified record is marked as deleted
     *                                  in the database file.
    long lock(int recNo, DB data) throws RecordNotFoundException {
        LOG.entering(this.getClass().getName(), "lock", recNo);
        synchronized (currentlyLockedMap) {
            try {
                while (currentlyLockedMap.containsKey(recNo)
                        && currentlyLockedMap.get(recNo)
                        != Thread.currentThread().getId()) {
                    currentlyLockedMap.wait();
                // Check if record exists.
                data.read(recNo);
                long cookie = Thread.currentThread().getId();
                currentlyLockedMap.put(recNo, cookie);
                LOG.fine("Thread " + Thread.currentThread().getName()
                        + "got Lock for " + recNo);
                LOG.fine("Locked record count = " + currentlyLockedMap.size());
                LOG.exiting(this.getClass().getName(), "lock", true);
                return cookie;
            } catch (InterruptedException ie) {
                throw new SystemException("Unable to lock", ie);
     * Releases the lock on a record. The cookie must be the cookie returned
     * when the record was locked.
     * @param   recNo                   the assigned primary key of the record
     *                                  to be unlocked after an operation.
     * @param   cookie                  the cookie returned when the record was
     *                                  locked.
     * @throws  RecordNotFoundException if specified record does not exist or if
     *                                  specified record is marked as deleted
     *                                  in the database file.
     * @throws  SecurityException       if the record is locked with a cookie
     *                                  other than cookie.
    void unlock(int recNo, long cookie) throws RecordNotFoundException,
            SecurityException {
        LOG.entering(this.getClass().getName(), "unlock",
                new Object[] { recNo, cookie });
        synchronized (currentlyLockedMap) {
            checkLock(recNo, cookie);
            currentlyLockedMap.remove(recNo);
            LOG.fine("released lock for " + recNo);
            currentlyLockedMap.notifyAll();
        LOG.exiting(this.getClass().getName(), "unlock");
     * Checks if the given record is locked before doing any modification or
     * unlocking for the record.
     * <p/>
     * Checks the <code>Map</code> of record number keys and cookie values
     * to see if it contains the given record number.
     * @param   recNo                   the assigned primary key of the record
     *                                  to be checked if it is locked.
     * @param   lockCookie              the cookie returned when the record was
     *                                  initially locked.
     * @throws  SecurityException       if no lock exists for the record or if
     *                                  the record has been locked with a
     *                                  different cookie.
    void checkLock(int recNo, long lockCookie) throws SecurityException {
        LOG.entering(this.getClass().getName(), "checkLock",
                new Object[] { recNo, lockCookie });
        // Check if record has been locked
        if (!currentlyLockedMap.containsKey(recNo)) {
            throw new SecurityException(ResourceBundle.getBundle(
                    "resources.ErrorMessageBundle").getString(
                    "lockNotAppliedKey"));
        // Check if record has been locked by different cookie.
        if (currentlyLockedMap.get(recNo) != lockCookie) {
            throw new SecurityException(ResourceBundle.getBundle(
                    "resources.ErrorMessageBundle").getString(
                    "notLockOwnerKey"));
        LOG.exiting(this.getClass().getName(), "checkLock");
}Edited by: Yucca on May 23, 2009 8:16 PM
Edited by: Yucca on May 23, 2009 8:18 PM

Answer 1

It is my understanding that RMI server can cater for eg 100 clients by spawning 100 threads at random for each client.No. It spawns a new thread for every new connection. At the client end, RMI makes a new connection for every call unless it can find an idle connection to the same host that is less than 15 seconds old. So if the client is doing concurrent calls there will be concurrent threads at the server for that client.
This process is not managed (thread wise)'Managed' meaning what?
the result is that 20 clients wishing to update record A can do so at will?The result is that an RMI server is not thread safe unless you make it so.
a) Synchronise (expensive)Compared to a database update the cost of synchronization is trivial.
b) implement a lock manager. The database should already have one of those, and so does java.util.concurrent. Don't write your own. Personally I would just syncrhonize around the database calls.
what happens if for eg the 1st RMI client dies and has its thread(a) the client doesn't have a thread, see above. The call has a thread.
(b) at the server, the call will execute, regardless of the state of the client, until it is time to write the result back to the client, at which point the write will encounter an IOException of some description and the thread will exit.
blocking all other threads from locking the same record?That can't happen unless you foul up your concurrency management.
Does the thread die with the clientIt dies with the call.
is there a need to worry about the RMI connection dying during the middle the locking operation.The server JVM won't notice until it is time to write the call result back, see above.