NX: Maintain Look Cookie in DBAdapter

[Jonathan Liu]

Because my assignment is URLyBird 1.2.1
the lock signature is:

     
public long lockRecord(long recNo) throws RecordNotFoundException;
public void unlock(long recNo, long cookie) throws SecurityException;[ 

I want to use an easy way to deal with Data.java, so I implement it as a singleton, and client can get this object from DBAdapter object. Every client will have their own DBAdapter, so I use an instance long number to record the lock cookie like this:

 
public class DBAdapter{
    private long lockCookie;
    private Data database=Data.getInstance();
    public update(long recNum){
        lockCookie=database.lock(recNum);
        database.update(recNum,lockCookie);
        database.unlock(recNum);
}
}
 

please give some comments.
thanks!

[Jonathan Liu]

I just want my project easy and works
but in the network mode, is this aproach still works ?
it seems that my code can't deal with client crash.
please help me
[ September 23, 2003: Message edited by: Jonathan Liu ]

[Hugh Johns]

I have a similiar threading structure, so I would be interested to hear if one of experts could comment on this approach...
My code structure is very similiar to the above...
I am using a singleton data class, every client will get an adaptor instance
which is again quite similiar the above code eample, except all the adaptor instances share a common static data instance (which contains the hashmap for locks). Does this server side locking look correct. At this stage I am not getting too worried about crashing clients (dangerous attitude?)

[Andrew Monkhouse]

Hi Jonathan,
Is your DBAdapter in the server or client code?
Many people have received very good scores without worrying about client's crashing. But if you would like to look at crash recovery, then there are plenty of people here who are willing to help. Search for WeakHashMap or Unreferenced in this forum if you would like some ideas.
Regards, Andrew

[Philippe Maquet]

Hi Jonathan and Hugh,
I just wrote something about the WeakHashMap solution for assignements with lock cookies in
this thread (RMI confusion).
Best,
Phil.

[Jonathan Liu]

Thank you Philippe,
I have read the thread, but I still don't quite understand.
It seems that in my design, I have no place to deal with client crash. Is this a big problem ?
And will RMI gurantee my DBAdapter unique for every client?

[Philippe Maquet]

Hi Jonathan,

It seems that in my design, I have no place to deal with client crash. Is this a big problem ?

It's just a "plus" many people who passed did not implemented, AFAIK.

And will RMI gurantee my DBAdapter unique for every client?

I know it's possible, but I don't know how (I use sockets). So I let the question for an RMI specialist ...
Best,
Phil.

[Andrew Monkhouse]

Hi Jonathan,

And will RMI gurantee my DBAdapter unique for every client?

Not of itself. If you want to guarantee a unique DBAdapter for each client, then you should look at using a connection factory.
If all you have is one DBAdapter registered with the RMI Registry, then that one instance will be used by all the connected clients. RMI will allow more than one thread to use your instance of DBAdapter, but there are no guarantees about which thread will be used by any given client at any given time (that is - one client could use two different threads for two consecutive method invocations, or two clients could use the same thread for non concurrent method invocations).
In a way you have answered my question about whether DBAdapter is on the client or the server. It must be on the server.
That being the case, I would invite you to consider two things:

what is the point of the cookie? Since your code will work identically with or without the cookie, the cookie has no value. No client can directly call lock, update, or unlock, so the whole point of the cookies is lost. Given that, do you think that Sun were hinting that the DBAdapter.update() method should be on the client side, in which case the cookies make sense?

Do you have the statement in your instructions: "Your server [...] must provide locking functionality as specified in the interface provided above" (in the Locking section under the interface description). If so, do you believe you are meeting this "must" requirement?

Regards, Andrew

[Jonathan Liu]

Hi Andrew
I am really sorry, I wrote the wrong code in the previous post. The code should be:

 
public class DBAdapter{    
    private long lockCookie;    
    private Data database=Data.getInstance();    
    
    public update(long recNum){        
        lockCookie=database.lock(recNum);       
        database.update(recNum,lockCookie);    
        database.unlock(recNum,lockCookie);
    }
} 
 

in the assignment is says:

Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

So in my Data.java I wrote:

 
public class Data implements DBAccess {
    private  HashMap lockList = new HashMap();
    public  long lockRecord(long recNo) throws
        RecordNotFoundException {
            if (recNo>getRecordCount()||recNo<0){
                throw new RecordNotFoundException();
            }
        long lockResult = 0;
        synchronized (lockList) {
            while (lockList.containsKey(new Long(recNo))) {
                try {
                    wait();
                } catch (InterruptedException e) {}
            }
            Random ra = new Random();
            lockResult = ra.nextLong();
            lockList.put(new Long(recNo), new Long(lockResult));
        }
        return lockResult;
    }
    }
 

This is my way to implement lock in Data.java

If all you have is one DBAdapter registered with the RMI Registry, then that one instance will be used by all the connected clients. RMI will allow more than one thread to use your instance of DBAdapter, but there are no guarantees about which thread will be used by any given client at any given time (that is - one client could use two different threads for two consecutive method invocations, or two clients could use the same thread for non concurrent method invocations).

Yes, I will use a Factory and return a DbAdapter instance for each client,so each client will have it's own DbAdapter and in turn gets it's own cookie. And this DbAdapter is inside server side, client won't know about the cookie,
But if no guarantee each client will still get it's own DbAdapter, then my design will be totally wrong, because the cookie will not be correct.

[Hugh Johns]

As mentioned above I am using a similiar server structure to Jonathan.
I am a bit stuck on a problem involving constructors,
Because of file access, my data class constructor (instance) throws quite a number of exceptions, I am told this is OK.

public static Data instance() 
            throws IOException, FileNotFoundException,
        SecurityException, SingletonException
           {
               //construct a single Data instance
           }

I want to use a singleton data instance as a static member for all DBAdapter instances (DBAdapter hides the locking/unlocking) for db access.
But can I surround a member declaration/definition in a try/catch?, seems messy even if possible.
I see only two options...
1. I am going down the wrong path.
2. Since DBAdaptor is the final layer of the server side code, (an instance of DBAdaptor will be used in remoteImpl and directly as local access), should I catch all/most exceptions at this stage and log them as serverside exceptions with a System.out error message. passing such a large number of exceptions all the way to GUI exception handling seems like a lot of bother.
Advice would be appreciated to get over this hump.

[Andrew Monkhouse]

Hi Jonathan,

Yes, I will use a Factory and return a DbAdapter instance for each client,so each client will have it's own DbAdapter and in turn gets it's own cookie. And this DbAdapter is inside server side, client won't know about the cookie,
But if no guarantee each client will still get it's own DbAdapter, then my design will be totally wrong, because the cookie will not be correct.

Your concern "[/i]but if no guarantee[/i]" should be unwaranted. You will not be registering the DBAdapter with RMI Registry - you will be registering the factory. And then each client will get it's own DBAdapter from the factory.
What did you think about my comments about having the lock method (and the others) on the client side?
Regards, Andrew

[Andrew Monkhouse]

Hi Hugh,

But can I surround a member declaration/definition in a try/catch?, seems messy even if possible.

You should not be surrounding the member declaration/definition in try/catch statements. You should be surrounding the member assignment inside try/catch statements.
If you are going to use a singleton, then you should only need to assign the instance within the try/catch blocks once. From then onwards, you can just pass it to your DBAdapter's constructor.
Regarding the code snippet you posted.... normally the public getter (accessor) method of the singleton would be called getXXX. For example getData(). Also, you would not normally construct the instance of Data within that getter method.
Regards, Andrew

[Philippe Maquet]

Hi Andrew,

That being the case, I would invite you to consider two things:
what is the point of the cookie? Since your code will work identically with or without the cookie, the cookie has no value. No client can directly call lock, update, or unlock, so the whole point of the cookies is lost. Given that, do you think that Sun were hinting that the DBAdapter.update() method should be on the client side, in which case the cookies make sense?
Do you have the statement in your instructions: "Your server [...] must provide locking functionality as specified in the interface provided above" (in the Locking section under the interface description). If so, do you believe you are meeting this "must" requirement?

What do you mean exactly there ? That the DBAccess interface "must" be exposed to clients ? (you know that I don't do that, so your opinion here it's quite important to me).
My LockManager and my db package in general, as well as my network sockets implementation would support it without any change nor any issue (you know that I did it on purpose, especially in the locking area), but I don't intend to expose to clients more than a few "business" methods. Do you think that I should make the effort to implement DB commands client-side, even if I don't use them. Would it be risky not to do it ?
Best,
Phil.

[Andrew Monkhouse]

Hi Philippe,

What do you mean exactly there ? That the DBAccess interface "must" be exposed to clients ? (you know that I don't do that, so your opinion here it's quite important to me).

I believe so.
As I mentioned, I don't see any logical reason for having the cookies unless they are exposed to the client.
However this is confused by other versions of the assignments not using cookies, so that argument doesn't apply to them. And then why would Sun have one version of the assignment more difficult than the other?
However my reading of the instruction regarding the functionality that the server must provide, is that these are functions that must be provided to the client. And this should apply to all versions of the assignment (but then it could be open to interpretation).
I know people have passed without providing all interface methods to the client. Whether they passed by luck or whether by documenting well the reasons why they did not expose the interface, I don't know.

Do you think that I should make the effort to implement DB commands client-side, even if I don't use them. Would it be risky not to do it ?

I suspect that it is an issue of how well you have documented your design decision not to have all the methods client side.
---
I have considered whether I should start up a new topic for this. But the questions all seemed relevant to Jonathan's implementation. Hmmmm. Do you want to continue the discussion here or shall we move to another thread?
Regards, Andrew
[ September 25, 2003: Message edited by: Andrew Monkhouse ]

[Tony Collins]

I think hiding the DB functions is very sensible otherwise clients could lock records and not release them or attempt to lock multiple record and cause a deadlock situation.
When I buy a book on amazon.co.uk I can't directly query the DB with a SQL statement.
I may be wrong but it doesn't seem like common sense to allow users access to the db.
Tony
[ September 25, 2003: Message edited by: Tony Collins ]

[Andrew Monkhouse]

Hi Tony,
Yes, that is a very good reason for having business methods.
But does it meet the requirements? That is my question.
Regards, Andrew

[Tony Collins]

My requirements

Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above

So it doesn't say the server must supply an interface, so I think I'm OK.
It seems it's very easy to fail this project on little points, must be hard for those with English as a second language.
Tony

[Philippe Maquet]

Hi Andrew,

I have considered whether I should start up a new topic for this. But the questions all seemed relevant to Jonathan's implementation. Hmmmm. Do you want to continue the discussion here or shall we move to another thread?

I think it would be better to move to a new thread. This question is far more general (and important IMO) than the right location of lock cookies. Even if the assignments with lock cookies are more concerned, the question may concern all assignments as you mentioned yourself.
Do you start or do I ?
Best,
Phil.

[Andrew Monkhouse]

Hi Philippe,
New topic started for this.
Regards, Andrew
[ September 25, 2003: Message edited by: Andrew Monkhouse ]