aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking w/o cookies issues - Again! 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 "Locking w/o cookies issues - Again!" Watch "Locking w/o cookies issues - Again!" New topic
Author

Locking w/o cookies issues - Again!

Alex Matute
Greenhorn

Joined: Jun 28, 2005
Posts: 14
Hi all! I've read all the five threads concerning locking w/o cookies and I still have some doubts. I hope you're not tired of talking about it....

It seems, according to almost all that I've read in this forum, that the best solution is taking the Data instance as the identifier of the client, but i still have some doubts about it, especially in the "Data instance" part, because I can't imagine the idea of having several Data instances. I implemented that class as a singleton that provides unique access to the file. This solves issues concerning the multiple accessing to the file (i.e. using one RandomAccessFile per Data instance) and is logically the most natural representation of a file associated to a DBScheme (unique in the application, by the way), at least from my point of view.

Based on this and what was discussed about not using the thread's name or anything concerning threads to properly identify a Client, I believe the best answer should be implementing it on a higher level, say a "Room Manager" (I got the URLyBird project), a class that translates "records" into "rooms" using the Data singleton and is able to lock a "room" and link it to a unique client using either the cookies approach (which I haven't figured yet at all) or the "Room Manager" instance approach. I believe this solution is more accurate to the project design (at least mine) because a real implementation of a DB (essentially one of the main parts of the project needs) should not be related with such a higher level structure
like a network client is. Now that I think about it, maybe the idea of creating a singleton factory of clients and associate each with a set of locked rooms would not be such a bad idea...

Any thoughts?

If I insisted on the singleton approach of the Data class, what client identification solution would you recommend?

Thanx & have a nice day!


-------------------<br /> <br />SCJD
Daniel Dalton
Ranch Hand

Joined: Mar 20, 2005
Posts: 146
Hi Alex,

There's nothing stopping you implementing the Data class as a Facade. In particular, you could have multiple Data instances all sharing a singleton instance of another class which does the actual I/O on the database file.

As for cookies, there are several versions of the assignment around - the interface you're given will either specify cookies from the lock() method etc, or it won't (mine doesn't).

Does that give you any ideas?
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11484
    
  94

Hi Alex,

Welcome to JavaRanch and this forum.
I've read all the five threads concerning locking w/o cookies
All five

A quick search brought up the following topics:
  • NX: lock/unlock - how to identify clients without lock cookie (has multiple potential solutions)
  • NX Contractors: Data instances and locking
  • NX: Locking and Unlocking and Sun's Must Conditions
  • Lock Cookie Question
  • Problem with lock manager
  • More on locking
  • B&S no lock cookies
  • locking without cookies
  • Clarification on Record Lock without Cookie
  • Database Lock
  • There are several different solutions listed in amongst those threads (I think there are at least four different solutions listed, maybe five), several of which will work with a singleton Data class.

    Regards, Andrew


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

    Joined: Jun 28, 2005
    Posts: 14
    Daniel and Andrew,

    Thanx for replies, I've read all those threads and also have been thinking a lot about my solution. Here's what I've concluded:
    1. There must be multiple instances of the Data class, especially because, as far as I can see, it's the easiest way to identify a client and my specifications are clear about "locks a record so that it can only be updated or deleted by this client"
    2. Because I believe that only one db scheme must exist, I'll implement a singleton that represents it, modifies the signatures of

    into

    and provides the HD access, using the Data class as a facade. I still don't like the idea of writing something like:

    , I'm burning my brains here but I'll figure out with something...
    3. Because my assigments 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.", I guess I won't be able to implement a thick client... right?

    By the way, as you must have already noticed Daniel, I got the no cookies lock() method.

    Thnx a lot! It's very nice to read people who are in the same situation I am.This forum is a great idea!
    Ta Ri Ki Sun
    Ranch Hand

    Joined: Mar 26, 2002
    Posts: 442
    Originally posted by Alex Matute:

    1. There must be multiple instances of the Data class, especially because, as far as I can see, it's the easiest way to identify a client and my specifications are clear about "locks a record so that it can only be updated or deleted by this client"


    Why?
    Say there's a single instance of DBMain/Data/DataFacade shared by multiple clients, and your bookRoom method calls lock -> read -> modify -> unlock then surely the record can only be updated by this client
    Daniel Dalton
    Ranch Hand

    Joined: Mar 20, 2005
    Posts: 146
    Hi Ta Ri Ki Sun,


    Say there's a single instance of DBMain/Data/DataFacade shared by multiple clients, and your bookRoom method calls lock -> read -> modify -> unlock then surely the record can only be updated by this client


    The point of having an instance of the Data class per client is to enable identification of this client. There may be other possible ways of doing it, but in the absence of lock cookies, it's a simple and reasonable approach.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11484
        
      94

    Hi Ta Ri Ki Sun,
    [...]your bookRoom method calls lock -> read -> modify -> unlock then surely the record can only be updated by this client
    Sure, but you are not meeting the Data class' requirement that the lock method "locks a record so that it can only be updated or deleted by this client"

    That is - take your Data class and plug it into a different solution where you dont have have a bookRoom method on the server and you can no longer guarantee that the client who locked the record is the only one who can update or delete it.

    Regards, Andrew
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11484
        
      94

    Hi Alex
    Because my assigments 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.", I guess I won't be able to implement a thick client... right?
    Hmmm. Want to spend the next week just reading one topic discussing this? :roll: Take a look at "Should lock methods be callable by the client".

    Personally, I agree with your reading, but there are many others who dont. And it appears that either reading can lead to a pass mark.

    Regards, Andrew
    Ta Ri Ki Sun
    Ranch Hand

    Joined: Mar 26, 2002
    Posts: 442
    Originally posted by Andrew Monkhouse:
    Hi Ta Ri Ki Sun, Sure, but you are not meeting the Data class' requirement that the lock method "locks a record so that it can only be updated or deleted by this client"

    That is - take your Data class and plug it into a different solution where you dont have have a bookRoom method on the server and you can no longer guarantee that the client who locked the record is the only one who can update or delete it.

    Regards, Andrew


    Thanks Andrew
    I agree, and I've noted that in my choices document.
    With one day to go before my exam I'm not sure I want to rework my solution, I'll have to see what I lose on server once marked. I do feel just a little comfortable defending the solution though. Fingers crossed while I panic for a month or so
     
     
    subject: Locking w/o cookies issues - Again!