Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking w/o cookies issues - Again!

 
Alex Matute
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Daniel Dalton
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 11914
209
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
     
    Alex Matute
    Greenhorn
    Posts: 14
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 442
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 146
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Pie
    Posts: 11914
    209
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Pie
    Posts: 11914
    209
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 442
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic