why is it necessary for unLock() to check clientID?

[eric zhao]

I am quite confused about the lock and unLock thing on why the clientID is even an issue. They would always be called in first lock, then unlock
fashion, why is it even required to consider: when try to unlock a lock by different thread? Seems to me that would never happen.
and what should I use for clientID since it's required to do it SUN way
Thanks for your comments.

[BJ Grau]

A network accessible database that allowed clients to unlock records that they had not locked in the first place would be a very brittle system. Without some sort of control in place you have to trust your client code to always follow the rules. Bad idea.

[Max Habibi]

Hi Eric,
There are two approaches to getting Client lock ID(I�m going to assume that you�re handling your networking by using RMI).
The first is the use the ID of the thread doing the calling. This is the method that I prefer, since it seems to be SUN's goal in providing the method signature that they did. The drawback here is that a RMI implementation could, arguably, be implemented that didn't use the same thread ID for locking that it did for locking. However, to my knowledge, this is a purely theoretical objection, since no such RMI actually does so.
The second approach is to change the method signature on the lock/unlock, and explicitly passing in a client ID. The advantage here is that you're not tied into your networking implantation, that thus have a more robust solution. In a production enviroment, where I had some leeway, this is probably the way I would choose.
The disadvantage here is that you risking an automatic failure, since you're not, by definition, implementing the methods lock(int) and unlock(int), but rather two different methods, with different signatures, that you find to be more convenient.
Which one you decide to go with is your call. In the past, people have scored well with both approaches.

All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 08, 2003: Message edited by: Max Habibi ]

[eric zhao]

Thanks Max! I actually bought your book as my studying guide for this certificate test. It's a great book, thank you very much and OHIO STATE rocks!
Sadly, graduated from cleveland state, I end up as a programmer at another OSU (oklahoma) tough time for java newbies, I am happy at least I have a job and doing java programming that I like.
Thanks again for your help.

[eric zhao]

Hi, BJ:
Thanks for your comments. I didn't think about that the DATA part of this could be given out as a product. In that case, it makes sense to shield it with this ID thing. I was just thinking the whole thing as a product and thought we should hide lock/unlock all together.

And still quite hard to imagine a case where a developer would want to unlock something he didn't lock?
Thanks.

[Duane Riech]

I'm glad this issue came up. I'm using a class called LockTable which has two elements, String ThreadName which contains the name of the Thread which owns the lock and boolean lockStatus to indicate if the record is locked. I check who's trying to lock/unlock a record before any database manipulation occurs. On remote connection, THE NAME OF THE THREAD FOR A CLIENT CHANGES from one operation to another. I don't seem to have a unique threadname to compare. I'm on Windows 2000 box.
Am I doing something wrong or what can I do?

[Max Habibi]

Hi Duane,
Thread name's not guaranteed to be unique. Have you considered using the Thread reference itself? Remember, it's just a reference, so storing it is lightweight. Also, I'm suprised that the thread name changes. May I see the part of your code that stores the threadname, and the part that checks it?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]

[Duane Riech]

I'll try changing the String ThreadName to
Thread threadId.
I was testing on Thread.currentThread().getName(). I didn't realize it could change.
Thanks.

public class LockTable
{
private boolean LockStatus; /* Indicates whether a database is locked
or not. */
private String ThreadName; /* Thread ID of thread owning the lock. */
public synchronized void lockRecord( ) {

LockStatus = true;
ThreadName = Thread.currentThread().getName();
} /* ...end of method lockRecord()... */

/**
* This method determines if a Thread already owns a lock on a particular
* database record. If the record is owned by the executing Thread, true is
* returned. Otherwise, false is returned.
* @return boolean value indicating if the executing Thread owns the lock
* on a record.
*/
public boolean ownsLock( ) {
/*
If the executing Thread already owns the lock, return true.
*/
if ( ThreadName != null &&
ThreadName.equals(Thread.currentThread().getName())) {
return true;
}
/*
The record already has a lock owned by another Thread, don't allow access.
*/
else
return false;
} /* ...end of method ownsLock()... */
}

[Max Habibi]

Duane,
Let's start with basics, most of which will be redundant to you: I just want to establish a basis for discussion.
A given thread is really just s bundle of instructions. Your program may have any number of these bundles. You get one by default when you run the main(String args[]) method, but it can spawn others.
Now, when multiple clients try to access your server through RMI, one of two things happen.
1) they all come in on the very same thread.
2) each client is given a distinct thread.
since 1 can be thought of as a specialized case of 2, I'll concentrate on 2.
When client A connects to your server, RMI generates a Thread(remember, a thread is a bungle on instructions), that handle anything that client A wants. We'll call this thread A.
When client B connects to your server, it also gets it's own thread. We'll call that thread B.
So, if your lock method has a habit of saying: 'gee, let me get access to the current thread(A or B, in our case), and see if the record it's interested in is free. If so, then create a mapping entry that associates that the current thread to whatever record it wants. If not, wait until it is free, then create that mapping entry�.
Then, your unlock should say 'gee, the current thread is trying to unlock record number X. Is the current thread the one that is associated with record X in my mappings?'
Now, if your RMI implementation happens to have a single thread that handles the calls for every client(that is, thread A handles calls for client 1, client 2, etc.,), you�re still ok, because thread A won�t start working for client 2 until it�s done working for client 1.
Now, there are some people who read the java specification to mean that RMI could allocate one thread for part of client 1�s requests, and another for another part of client 1's requests. While this is open to debate (look over my previous posts if you want to see that debate), I don�t believe that there is any debate about the fact that no know RMI implementation actually does so.
Let me stop here, and see if all of this is clear.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Duane Riech]

I suppose so. Keep going....

[Duane Riech]

However RMI handles the communication back and
forth between the client/server, there has to be
SOME unique ID to identify who/whom to send each
packet to?
If RMI wants/doen't want to change threads to do
it fine. But there must be some unique tag.

[Max Habibi]

Originally posted by Duane Riech:
However RMI handles the communication back and
forth between the client/server, there has to be
SOME unique ID to identify who/whom to send each
packet to?
If RMI wants/doen't want to change threads to do
it fine. But there must be some unique tag.

Well, yes. However, RMI has no responsibility to make that hypothetical tag available to you. Thus, RMI switiching threads like that would be a deal breaker, as far as this solution algorithm is concerned.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]

[Max Habibi]

The challange is for you to keep track of the thread that locked a given record. To do that, you need access to whatever thread is making a locking request, by using

Thread currentThread = Thread.currentThread()

method. This static method returns a reference to the current thread that is trying to drive the lock/unlock method(or any method, for that matter).
Thus, for locking, you might create an association between this thread and the record it's trying to lock by putting that information into a map. I would suggest a static map structure that is shared by all instances of the Data method.
Something like

/*assume we're in a block synchronized on the map 
lockedRecords and that we've already checked that 
no other clients have locked this record
*/
lockedRecords.put(currentThread, new Integer(recno));

Your unlock method simply checks the that the Thread.getCurrentThread() method returns a reference to the thread that locked recno, and then unlocks it.
Make sense?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]
[ March 09, 2003: Message edited by: Max Habibi ]

[Duane Riech]

First, I apologize for not getting this...
You first state that there's no guarantee that
the same thread will be used for a client, then
you state in a example to use Thread.currentThread()???
I've just done some testing using this call...
You don't get the same ID. So whether you use a
simple algorthim or a map or whatever, you can
never compare thread's to know when the correct
thread is requesting to unlock.
So I just don't see what the map does for me.
RMI is not thread safe? Fine, but never supplying
a tag for each client is communicating to....
That's odd.

[John Smith]

The drawback here is that a RMI implementation could, arguably, be implemented that didn't use the same thread ID for locking that it did for locking. However, to my knowledge, this is a purely theoretical objection, since no such RMI actually does so.

In my tests, I conclusively proved that Sun's RMI is up to its specification, -- RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.
Here is the output of my simple test (I can post the source if anyone interested), where I create 2 clients, and each client makes 10 invocations of the same method:
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 1 used thread Thread[RMI TCP Connection(7)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
client 2 used thread Thread[RMI TCP Connection(6)-209.91.62.136,5,RMI Runtime]
As you can see, client 1 and 2 use the threads (6) and (7) interchangably, without a particular pattern.
My strong recommendation is to abandon the use of threads to identify the client and follow a standard RMI Factory approach for this assignment. This is the approach favored by a majority of people in this forum, and for a good reason, -- this is a simple, elegant, reliable, and standard solution to a standard problem.
Eugene.
[ March 09, 2003: Message edited by: Eugene Kononov ]

[Max Habibi]

Originally posted by Duane Riech:
First, I apologize for not getting this...
You first state that there's no guarantee that
the same thread will be used for a client, then
you state in a example to use Thread.currentThread()???

Not exactly. It is my interpretation that you will always get the same thread from RMI per client. However, there are people who feel that it would be possible to write an RMI implementation that does not do this: either way, I believe that both side agree that there is no such implementation: that is, you do always get the same thread ID. Since I don't want to discount their argument simply because I disagree with it, I am mentioning it.

I've just done some testing using this call...
You don't get the same ID. So whether you use a
simple algorthim or a map or whatever, you can
never compare thread's to know when the correct
thread is requesting to unlock.

Duane, you are free to disregard my advice if it's not helping you. I've had students earn perfect scores using exactly this algorithm, but maybe I�m not the right source of help for you.

So I just don't see what the map does for me.
RMI is not thread safe? Fine, but never supplying
a tag for each client is communicating to....
That's odd.

No in the way that you�re describing, no.
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

Originally posted by Eugene Kononov:

In my tests, I conclusively proved that Sun's RMI is up to its specification, -- RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.
Here is the output of my simple test (I can post the source if anyone interested), where I create 2 clients, and each client makes 10 invocations of the same method:
<snip>
[ March 09, 2003: Message edited by: Eugene Kononov ]

Hi Eugene,
I'd very much like to see your tests, as opposed to just their output. And I agree with you about the advocatacy of using the RMI factory. As a matter of fact, it's a linchpin on the approach. The factory is a remote instance, and it creates a unique remote data instance, one per client. Maybe I didn't explain this clearly before. Make sense, or should I provide an example?
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]

[John Smith]

I'd very much like to see your tests, as opposed to just their output.

Here is the complete source, very short and sweet, just 4 java files:

RemoteObject.java
-----------------
package suncertify.server;
import java.rmi.*;
public interface RemoteObject extends Remote {
    public String test(int client) throws RemoteException;
}
RemoteObjectImpl.java
---------------------
package suncertify.server;
import java.rmi.*;
import java.rmi.server.*;
public class RemoteObjectImpl extends UnicastRemoteObject implements RemoteObject {
    public RemoteObjectImpl() throws RemoteException {}
    synchronized public String test(int client) {
        return ("client " + client + " used thread " + Thread.currentThread());
    }
}
StartServer.java
----------------
package suncertify.server;
import java.rmi.*;
import java.rmi.registry.*;
public class StartServer {
    public static void main(String[] args) {
        try {
            LocateRegistry.createRegistry(1099);
            RemoteObjectImpl rmiObject = new RemoteObjectImpl();
            Registry registry = LocateRegistry.getRegistry(1099);
            registry.rebind("rmiService", rmiObject);
            System.out.println("Server started successfully");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
Test.java
----------------
package suncertify.test;
import suncertify.server.*;
import java.rmi.*;
import java.rmi.registry.*;

public class Test {
    public void testMultiClient() {
        // make 2 rmi clients
        for (int i = 1; i <= 2; i++) {
            new RMIClient(i);
        }
    }
    private class RMIClient extends Thread {
        private RemoteObject rmiObject;
        private int client;
        RMIClient(int client) {
            try {
                this.client = client;
                rmiObject = getRMIObject();
            } catch (Exception e) {
                System.out.println("Unexpected exception: " + e);
            }
            start();
        }
        public RemoteObject getRMIObject() {
            try {
                String service = "//localhost:1099/rmiService";
                RemoteObject remoteDataFactory = (RemoteObject) Naming.lookup(service);
                return remoteDataFactory;
            } catch (Exception re) {
                re.printStackTrace();
                return null;
            }
        }
        public void run(){
            try {
                for (int i = 0; i < 10; i++) {
                    // invoke the same method 10 times
                    String result = rmiObject.test(client);
                    System.out.println(result);
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    public static void main(String[] args) {
        try {
            Test test = new Test();
            test.testMultiClient();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Eugene.

[Max Habibi]

Eugene,
Just as I suspected, you're binding several threads to the very same object, thus bypassing the factory all together. In looking over my own post, I think I can understanding how this impression could be reasonably formed. My apologies for not being more clear.
I may not be explaining the approach very well: I'm putting together an example that does so now, hopefully without giving too much away. But the basic premise is that the factory creates a unique remoteData object per client. The contention is that each of these remoteData objects is, in turn, beholden to a single client, and a single thread. Thus, one thread per remote instance.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[John Smith]

Just as I suspected, you're binding several threads to the very same object, thus bypassing the factory all together.

Oh, so you are saying, "use the RMI factory, and use the thread as a client id?". But what's the point? If I have a connection object from the factory, then that object itself identifies the client uniquely. I don't need any thread ids anymore!
The bottom line, again, is that RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. This is not just a theoretical argument from the RMI spec, but a very verifiable and practical one. I hope we aree on that.
Eugene.

[Max Habibi]

Originally posted by Eugene Kononov:

Oh, so you are saying,

No, I am just saying, Inspector Cousou

"use the RMI factory, and use the thread as a client id?". But what's the point?

I'll explain the point, if you'll gather in the parlor.

If I have a connection object from the factory, then that object itself identifies the client uniquely. I don't need any thread ids anymore!

I'm not talking about the thread id, I'm talking about the thread reference. There's a big difference.

The bottom line, again, is that RMI runtime makes no guarantees with respect to mapping remote object invocations to threads.

While this is true, what it actually means is debatable, which is the point of this discussion. Some, including you and I and everyone else I know who is involved in this discussion, agree that it means that for a given remote object with n clients, there is not guarantee that that the object will consistently be called by thread t on behalf of client c. If it has multiple clients, it might, in fact, be called from various threads.
Others, and this is the part that's open to debate, feel that it means that for a given remote object with a single client, that object might still be called by various threads on behalf of that single client.
The part that is not open to debate, AFIK, is that there is no known implementation of RMI that actually will call a single remote object, which is bound to a single remote client, on various threads. Makse sense?

This is not just a theoretical argument from the RMI spec, but a very verifiable and practical one. I hope we aree on that.
Eugene.

Well, we do, but I�m afraid that we won't. That is, if it is verified through the example I will provide, I hope that you will agree. if it is refuted, then I will agree with you. Feel free to run the example on any OS. Deal?
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 09, 2003: Message edited by: Max Habibi ]

[Max Habibi]

Eugene,
You are correct, and I was mistaken. It is, in fact, possible for a single client, bound to a single remote instance, to have it's methods called by various threads. May I have some salt with my crow?
My apologies,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

[UPDATED]
Duane,
My apologies on any confusion I've caused on this issue. It seems that you will, in fact, need to either modify the signature of the lock method, so that it can accept a client ID, or use the this object, in the data class, to act as a key.
The latter requires the use of the RMI factory pattern, as Eugene suggested. Again, please accept my apologies. The success of some of my students with that method, along with my own observations with other jdks, led me to a false conclusion.
best wishes,
M
[ March 10, 2003: Message edited by: Max Habibi ]

[Raffe Paffe]

Max,
You said

The disadvantage here is that you risking an automatic failure, since you're not, by definition, implementing the methods lock(int) and unlock(int), but rather two different methods, with different signatures, that you find to be more convenient.

After this dissuction should I leav the lock and unlock in Data and implement it in a lockmanager. Is that ok?

[John Smith]

It seems that you will, in fact, need to modify the signature of the lock method, so that it can accept a client ID.

Just to clarify something, -- the fact that you can't rely on threads to identify the clients does not mean that the signature of lock/unlock needs to be modified. A common solution here (seems like a consensus solution) is to leave the lock/unlock methods in Data empty, and implement them in RemoteData as follows:

    public void lock(int recNum) throws RemoteException,
           IOException {
        recordLockManager.lock(recNum, this);
    }
    public void unlock(int recNum) throws RemoteException {
        recordLockManager.unlock(recNum, this);
    }

The "this" reference points to the connection object created from the RMI factory.
Eugene.

[Max Habibi]

Hi Raffe,
That's one way to go, but it's not neccessary. The same idea as discussed above, but storing the this object as the key, instead of the thread, will allow you to adheare to the signature of the method. It's a minor tweak, codewise. Would you like an example?

M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Max Habibi]

I agree that you can use the this, per my modified post this morning, though I would use the this as a key, and the record num as the value.
However, not implementing the lock method in data seems a little drastic to me. Why not implement lock/unlock in the data class, and use delegation in RemoteData? That way, you're adhearing to the specs.

M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Raffe Paffe]

Eugene , Max
Thanks you both for you coments. I must say that I am confused about lock/unlock in Data. Currentlly I have not implemented anything in Data. But now (after this topic) I feel that I must.
Eugene , can you say that people have passed the exame without implementing anything in Data (lock/unlock)?
My code looks like this now. This is the RemoteDataImpl.

 public class RemoteDataImpl extends UnicastRemoteObject implements DataInterface , Unreferenced{
    private Data database;
    private LockManager lockManager;
    public RemoteDataImpl(RemoteDatabase remoteDataAndLockManager) throws RemoteException {
      this.database = remoteDataAndLockManager.getDatabase();
      this.lockManager = remoteDataAndLockManager.getLockManager();
    }
    public void lock(int record) throws DatabaseException, RemoteException {
      lockManager.lock(record,this);
    }
    public void unlock(int record) throws RemoteException {
      lockManager.unlock(record,this);
    }
//....
} 

and here is the LockManager:
Now, how should this be transformed into Data?

 public class LockManager {
  private Map mapLocks = new HashMap();
  private final int DATABASE_LOCK = -1;
  private final Integer ALL_DATABASE_LOCKED = new Integer(DATABASE_LOCK);
  public LockManager() {
  }
  synchronized public void lock(int recNum, Object clientId) throws DatabaseException{
    Integer recordNumber = new Integer(recNum);
    if ( recNum == DATABASE_LOCK ) {
      while (!mapLocks.isEmpty()) {
        try {
          System.out.println(clientId.toString()+" Waiting for all database unlock.");
          wait();
          } catch (InterruptedException e) {
             throw new DatabaseException("Interrupt ocurred. Could not complete lock");
          }
      }
    } else {
      while (mapLocks.containsKey(recordNumber) || mapLocks.containsKey(ALL_DATABASE_LOCKED) ) {
        try {
          System.out.println(clientId.toString()+" Waiting for record unlock.");
          wait();
          } catch (InterruptedException e) {
             throw new DatabaseException("Interrupt ocurred. Could not complete lock");
          }
      }
    }
    mapLocks.put(recordNumber, clientId);
  }
  synchronized public void unlock(int recNum, Object clientID) {
    Integer recordNumber = new Integer(recNum);
    if (mapLocks.get(recordNumber).equals(clientID)) {
      mapLocks.remove(recordNumber);
      System.out.println(clientID.toString()+" Unlocked the record.");
      notifyAll();
    }
  }
  synchronized public void clearClientLocks(Object clientId) {
    Iterator iter = mapLocks.entrySet().iterator();
    while (iter.hasNext()) {
      Map.Entry entry = (Map.Entry)iter.next();
      if (entry.getValue().equals(clientId)) {
        mapLocks.remove(entry.getKey());
        notifyAll();
      }
    }
  }
   synchronized public boolean isRecordLocked (int recNum, Object clientID) {
     Integer recordNumber = new Integer(recNum);
     if (mapLocks.get(recordNumber).equals(clientID)) {
       return true;
     }
     else {
       return false;
     }
   }
}
 

Max, could you provide the example you were talking about?
Puh! This subject got me nervous! :-)

[John Smith]

Max Habibi wrote:
Eugene,
You are correct, and I was mistaken. It is, in fact, possible for a single client, bound to a single remote instance, to have it's methods called by various threads. May I have some salt with my crow?

Well, the only person who never makes mistakes is Peter den Haan. Sometimes I think he is not human.

Max Habibi wrote:
However, not implementing the lock method in data seems a little drastic to me. Why not implement lock/unlock in the data class, and use delegation in RemoteData? That way, you're adhearing to the specs.

Yes, that seems like an obvious approach and that was how I designed it initially. However, that implies that locking will occur in non-networked mode.

Raffe Paffe wrote:
Eugene , can you say that people have passed the exame without implementing anything in Data (lock/unlock)?

Yes, I am one of these people, and I got a maxumum score for my server design with this implementation. Your lock manager and RemoteDataImpl code look fine.
Eugene.
[ March 10, 2003: Message edited by: Eugene Kononov ]

[Raffe Paffe]

Eugene , a followup. Did your specs. say :

Following is a description of the package that is provided, and of the extensions you are expected to implement.
[...]Part of your assignment will be to enhance the Data class. You may do this by modification or subclassing, but you should document the approach and reason for your choice.

English is not my native language so i am unsure...

[John Smith]

English is not my native language so i am unsure...

What's the question?
Eugene.

[Max Habibi]

Originally posted by Eugene Kononov:
[QB]
Yes, that seems like an obvious approach and that was how I designed it initially. However, that implies that locking will occur in non-networked mode.

The way that you ended up with is actually the way I started with. However, I ended up changing it. My reasoning is this:
1. The instructions say that you need to implement the lock/unlock methods in data. They are very specific on this point.
2. There are other methods, like add and delete, that while available, are not used. lock/unlock can easily fall into that category.
3. The local implementation does not need to call lock/unlock.
The strongest of these arguments, to me, was the first.
All best,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4

[Raffe Paffe]

Ok, thanks all for your answers. I choose to inplement lock/unlock in Data. Now, how do i do that?

[Miguel Roque]

Hello.
One question regarding the lock. I've read many posts concerning this subject. The instructions specific say that you must implement the lock/unlock in the data class. If we change the method signature we risk to break existent code in use, so why don't we create a lock manager class when we open a database and we use it inside the lock(int)/unlock(int) with a reference to the Data class to get the client ID (this way we can use this class in a multithreaded environment). Besides this we add two new methods to the Data class that besides the record number also accepts a object that will be used as client ID and these methods also calls the lock manager?
This ways in a remote data implementation we use the new methods with the remote reference as client ID and in a local data implementation the original methods are used.
Thanks,
Miguel

[Raffe Paffe]

Miguel ,
Do you mean that we create a method
public void lock(int record, Object clientId)
and let that method call public int lock(int record) somehow ? As I read the spec we must implement lock in public int lock(int record).
Any comments??

[Miguel Roque]

Hello.
What I mean is, you have two classes, LocalDataImpl for local access and other RemoteDataImpl for remote access. Both classes have instances of Data class and define all the public interface of the original Data class (i.e. the method lock(int)/unlock(int)).
Inside these methods you call in local implementation the methods lock(int)/unlock(int) in the Data class and in the remote implementation you call the methods lock(int,Object)/unlock(int/Object) that also are in the Data class.
I'm considering this implementation due to the fact that Data class is thread safe, so can be used in a multithreaded environment even in local mode, so two different threads can operate on the same record meaning that we must have some way to lock/unlock the records.
With this implementation, specific javadoc comments should be placed in the Data class so that a final user should know the methods to use when locking records if in local mode or remote mode.
Comments please.
Miguel

[Raffe Paffe]

Miguel,
I think i understand your implemenation but what will you send to lock(int i). Is it the recordid or the clientId ?
Now, my question. The spec says:

public void lock(int record)
public void unlock(int record)
Record locking must be implemented using the methods public void lock(int)
and public void unlock(int)

So can you implement the locking using lock(int,Object)/unlock(int/Object) ? I dont know. Can we figure out a way to not add lock(int,Object)/unlock(int/Object) to data ?

[Miguel Roque]

Hi Raffe.
You can implement lock(int,Object) outside the Data class. In your local data implementation you will have something like:

  
public void lock(int record) throws IOException {
    data.lock(record);
}

While in remote data implementation you have two options. Using the new methods of Data class that accepts the client ID will be:

  
public void lock(int record) throws IOException {
    data.lock(record, this);
}

If using the lock manager class outside the Data class, something like the following:

  
public void lock(int record) throws IOException {
    lockManager.lock(record, this);
}

By putting the two new methods in the Data class, we avoid the creation of two objects that where LockManager inside the Data class and a LockManager inside the RemoteDataImplementation.
Miguel

[Raffe Paffe]

Miguel,
I understand. Thanks.
But

Record locking must be implemented using the methods ....

I understand the use of the lockmanager and so on. But can we implement locking somewhere else if you look at what they are wrinting ???

[Max Habibi]

Originally posted by Raffe Paffe:

Max, could you provide the example you were talking about?
Puh! This subject got me nervous! :-)

Sure. A word of explanation. There are three important classes here: the rest are interfaces, and self explanatory.

A FactorypImpl that creates a generic factory, used by all clients, to get a remoteData object.

RemoteDataIampl that provides the functionality of a remote object. It offers two methods, doStuff and undoStuff, that might look familiar.

ClientDriver that creates 20 separate threads. Each thread creates gets a remoteData object by using the Factory. The then doStuff, wait a bit, then undoStuff.

to run the example, type in the following

javac RemoteDataImpl.java
javac FactoryImpl.java
javac ClientDriver.java

rmic RemoteDataImpl
rmic FactoryImpl
java FactoryImpl
java ClientDriver

One of the important things to notice here is that this design, the RemoteDataImpl classes uses the client itself as a key. Thus, you get free releasing of locks if a client dies. If you want more on this, read about weakHashMaps, which are a great little gem.
FactoryImpl

import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;

public class FactoryImpl extends UnicastRemoteObject implements Factory
{
    private static int clientCount = 0;
    public static final String FactoryName = "//localhost/Factory";
    public FactoryImpl() throws RemoteException {
        super();
    }
     /*
     * returns a unique RemoteData object
     *
     * @throws RemoteException
     */
    public synchronized RemoteData createRemoteConnection() throws RemoteException{
        clientCount++;
        //creare and bind a unique object per server
        String bindingName = "//localhost/RemoteData" + clientCount;
        RemoteData remoteData = null;
        try {
            remoteData = new RemoteDataImpl(bindingName);
            Registry registry = LocateRegistry.getRegistry(1099);
            registry.rebind(bindingName, remoteData);
            System.out.println("RemoteData bound");
        } catch (Exception e) {
            System.err.println("RemoteData exception: " + e.getMessage());
            e.printStackTrace();
        }
        return remoteData;
    }
    public static void main(String[] args) {
        try {
          Registry registry = LocateRegistry.createRegistry(1099);
          Factory factory = new FactoryImpl();
          registry.rebind(FactoryName, factory);
          System.out.println("Factory bound");
        }
        catch (Exception e) {
            System.err.println("Factory exception: " + e.getMessage());
            e.printStackTrace();
        }
    }
}

RemoteDataImpl

import java.rmi.*;
import java.rmi.server.*;
import java.util.*;

public class RemoteDataImpl extends UnicastRemoteObject
                           implements RemoteData
{
    private static Map lockedRecords = new WeakHashMap();
    private String bindingName;
    public RemoteDataImpl(String bindingName) throws RemoteException {
        super();
        this.bindingName = bindingName;
    }
    public void doStuff(int recno) throws RemoteException{
        synchronized(lockedRecords){
          Integer rec = new Integer(recno);
          while (lockedRecords.containsValue(rec)){
              try{
                  String msg  =bindingName + " is WAITING to lock record " + recno;
                System.out.println(msg);
                lockedRecords.wait();
                }
              catch(InterruptedException ie){
                  ie.printStackTrace();
              }
          }
          String msg  =bindingName+ " is LOCKING record " + recno;
          System.out.println(msg + "\n"+ bindingName);
          lockedRecords.put(this, rec);
          lockedRecords.notifyAll();
        }
    }
    public void undoStuff(int recno) throws RemoteException{
        synchronized(lockedRecords){
          Integer rec = new Integer(recno);
          Integer lockRecno = (Integer)lockedRecords.get(this);
          if (lockRecno != null && lockRecno.equals(rec)){
              String msg  =bindingName + " is UNLOCKING record " + recno;
              System.out.println(msg+ "\n"+ bindingName);
              lockedRecords.remove(this);
          }
         lockedRecords.notifyAll();
         if (lockedRecords.isEmpty()){
             System.out.println("all records released");
         }
        }
    }
}

ClientDriver

import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
public class ClientDriver extends Thread{
  private int recno;
  private static Factory factory = null;
  private static Registry registry = null;
    static{
        try {
            registry = LocateRegistry.getRegistry(1099);
            factory = (Factory)registry.lookup(FactoryImpl.FactoryName);
            }
            catch (Exception e) {
                e.printStackTrace();
            }
    }
    public static void main(String args[]){
        for (int i=0; i < 20; i++){
            ClientDriver cd = new ClientDriver();
            cd.recno = i;
            cd.start();
        }
    }
    public void run(){
            try{
              RemoteData client = factory.createRemoteConnection();
              System.out.println("RemoteData bound");
              int recordToLock = recno %3;
              client.doStuff(recordToLock);
              rest();
              client.undoStuff(recordToLock);
            }
            catch (Exception e) {
                System.err.println("RemoteData exception: " + e.getMessage());
                e.printStackTrace();
            }
    }
    public static void rest(){
        try{
            long tmp = 3000 ;//* (long)Math.random();
            Thread.currentThread().sleep(tmp);
        }
        catch(InterruptedException ie){
            ie.printStackTrace();
        }

    }
}

Factory

import java.rmi.*;
import java.rmi.server.*;
/**
 * provides a public interface for the factory used to create
 * Remote Objects
 */
public interface Factory extends Remote
{   /**
     * returns a unique RemoteData object
     *
     * @throws RemoteException
     */
    public RemoteData createRemoteConnection() throws RemoteException;
}

import java.rmi.*;
import java.rmi.server.*;
public interface RemoteData extends Remote
{
    public void doStuff(int renco ) throws RemoteException;
    public void undoStuff(int recno) throws RemoteException;
}

HTH
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ March 11, 2003: Message edited by: Max Habibi ]