aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Maintain Look Cookie in DBAdapter Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Maintain Look Cookie in DBAdapter" Watch "NX: Maintain Look Cookie in DBAdapter" New topic
Author

NX: Maintain Look Cookie in DBAdapter

Jonathan Liu
Greenhorn

Joined: Aug 21, 2003
Posts: 26
Because my assignment is URLyBird 1.2.1
the lock signature is:

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:

please give some comments.
thanks!
Jonathan Liu
Greenhorn

Joined: Aug 21, 2003
Posts: 26
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
Ranch Hand

Joined: Jul 28, 2003
Posts: 36
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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11279
    
  59

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
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
Greenhorn

Joined: Aug 21, 2003
Posts: 26
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
Bartender

Joined: Jun 02, 2003
Posts: 1872
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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11279
    
  59

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
    Greenhorn

    Joined: Aug 21, 2003
    Posts: 26
    Hi Andrew
    I am really sorry, I wrote the wrong code in the previous post. The code should be:

    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:

    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
    Ranch Hand

    Joined: Jul 28, 2003
    Posts: 36
    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.

    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
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11279
        
      59

    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
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11279
        
      59

    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
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    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
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11279
        
      59

    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
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    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
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11279
        
      59

    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
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    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
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    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
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11279
        
      59

    Hi Philippe,
    New topic started for this.
    Regards, Andrew
    [ September 25, 2003: Message edited by: Andrew Monkhouse ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: NX: Maintain Look Cookie in DBAdapter
     
    Similar Threads
    forced to lock and then read
    NX: Passed B&S 387/400
    NX: Help, how to notify all Data objects in unlock()?
    I passed, but I suffered the 44/80 locking penalty. Why?
    How to use lock cookie to identify a client?