aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX:  Locking and Unlocking and Sun's Must Conditions 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:  Locking and Unlocking and Sun Watch "NX:  Locking and Unlocking and Sun New topic
Author

NX: Locking and Unlocking and Sun's Must Conditions

Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,

Here are some must conditions for this assignment:

So, here's the problem, and again, it has to do with Sun's must
conditions (assuming that my design and initial rough drafts
at implementation are logically correct).
The problem is that I seem to have created a system where the
use of the three methods involved in locking within DBMain
are totally unnecessary! That is, it seems that my system is
logically correct without using lock(), unlock(), and isLocked().
My macro server design which addresses these synchronization
issues is pretty straightforward:
multiple clients use the server, and
multithreaded remote method of server invokes
singleton DataManager methods with each business method (such as "book()") synchronized
which in turn uses Data
which in turn uses a RandomAccessFile
which in turn uses a physical random access file.
Note that the because DataManager is a singleton, then
there is only one DataManage, one Data, one RandomAccessFile,
and one physical random access file. And, again, DataManager's
methods are synchronized, i.e., public void synchronized doSomethingMethod() {}
So, I just don't see how Sun's must methods of lock(),
unlock(), and isLocked() have any relevance. But, of course,
who wants automatic failure?
Okay, I knew I left something out; here are Sun's supplied
comments for these three methods as found in the
DBMain Java interface code:
lock(): ""
Well, what is "this client" mean; if my threads are controlled, I don't
care exactly which client "this client" is, right?
unlock(): "."
isLocked(): ""
So, in conclusion, I see nothing in my particular specifications
which mandates that locking a record and associating this
lock to a specific client is required. If this assertion is true,
then perhaps I've gotten an easier version of the assignment
than other postings I've seen here.
Except for the one must condition that I implement the
DBMain Java interface, in which case I need to implement
lock(), unlock(), and isLocked() even though to do so would,
it appears to me, be completely silly given my design.
So, does anyone care to venture a guess as to what will
happen if I don't implement lock(), unlock(), and isLocked()
(assuming that I justify not using them as I have here)?
That is, these three methods would simply and literally do nothing
(that is, they would be trivially implemented).
Finally, is there some fatal flaw in my simple design which I haven't
considered (and, yes, I have not yet considered in my own thinking
process issues of clients dying, or a thread of mine for some mysterious
reason going into an infinite loop); that is, I'm not sure that these
are things that are realistic for me to be overly concerned about
at this time, but I may be completely wrong as this topic of locking
records and using RMI are new to me.
Thanks,
Javini Javono
[ January 07, 2004: Message edited by: Javini Javono ]
[ January 07, 2004: Message edited by: Javini Javono ]
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,
Before I posted my question, I looked through some of the recent posts to see
what was said. And, after posting the above question, I looked a second time
at some of them.
I think I'm beginning to see why some implementations are using associating
client ID's with a record lock: this is what is called "client-side record locking"
wherein multiple clients talk to the server specifying the business command
they need performed as well as a record number; the server is then responsible
for making sure no two different clients are simultaneously operating on the
same record.
And, my design, would be called a "server-side record locking" scheme. The
same process occurs in the front end, in that multiple clients with different
ID's may attempt to simultaneously book the same record in the file, but
the fact that my business methods, such as book(), are synchronized, the
client ID is completely irrelevant, and I let the Java programming language
ensure that my file does not get corrupted.
Well, perhaps I don't really understand the difference yet, because in both
cases the server is making sure that multiple clients don't corrupt the file;
the only difference is that one design literally creates, let's say, a Map
to associate record numbers and client ID's, while designs of my type
don't concern themselves with the specific client ID, only that within
some thread you have "this client" and what "this client" refers to
is not relevant due to method synchronization.
So, what are the benefits of the more complicated locking schemes wherein
you keep track of the unique client ID? The only possible benefit would
be that you could create two queues of business requests: one queue
for business requests that only require reading, and one queue of
business requests which requite reading and writing, and possible one
queue wherein the file size might change. Then, for example, you
could fire off all the requests in "reading queue" as individual threads
to operate on a file stored in memory, and thus processing would be
faster.
Am I beginning to understand the subtleties of the design choices
I've been reading about?
Thanks,
Javini Javono
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11525
    
100

Hi Javini,
The problem with your "simple" solution is that it does not cater for the situation where two client applications try to book the same record at the same time. That is:
  • GUI Instance 1 searches for available rooms in Smallville: 1 room returned
  • GUI Instance 2 searches for available rooms in Smallville: 1 room returned
  • GUI Instance 1 tries to book that one room
  • GUI Instance 2 tries to book that one room


  • Now what happens? As far as I can tell from your scenario, both bookings will work. Which means that two people will turn up at that hotel expecting to have a bed. Perhaps they can share it?
    I will let you think about that for a moment ... the solution involves using the lock method
    Regards, Andrew


    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi Andrew,
    and thanks very much for writing. I will quote your response so that I
    can in more detail explain what I am saying, and perhaps in this
    process I will stumble upon the flaw in my design that you suggest
    exists (and, obviously, if there is a flaw, then I want to find out about
    it through two or more possible methods: that is, I find out about it
    because there is a flaw in my understanding of the mechanics of the
    Java language, or I find out about it because there is a flaw in the bare
    logic I am relying on, or I find out about it when I get to the implemenation
    stage and through testing where multiple threads attempt to reserve exactly the
    same room "at the same time" (though this may be hard to set-up in
    a test in that there may be no guarantee that the system will time slice
    these threads)).
    ********************************************
    Originally posted by Andrew Monkhouse:
    The problem with your "simple" solution is that it does not cater for the situation where two client applications try to book the same record at the same time. That is:
    GUI Instance 1 searches for available rooms in Smallville: 1 room returned
    GUI Instance 2 searches for available rooms in Smallville: 1 room returned
    GUI Instance 1 tries to book that one room
    GUI Instance 2 tries to book that one room
    Now what happens? As far as I can tell from your scenario, both bookings will work. Which means that two people will turn up at that hotel expecting to have a bed. Perhaps they can share it?
    I will let you think about that for a moment ... the solution involves using the lock method
    ********************************************
    While it's true that I said I don't care about the client ID, let me correct this somewhat
    mis-spoken notion. I do care about the individual client ID because the client ID will
    be used to identify that the record has been booked by a specific client; that is,
    there is a field in each record and it will be blanks when no one has booked the room,
    and it will be filled with a unique client ID if that room has been booked by any
    specific client.
    However, I won't be storing a Map associating records in the file with client ID's for
    the purposes of locking and unlocking because my business logic class is a singleton
    and it's methods, such as book(), will be synchronized. In fact, as I stated above,
    I'm having a hard time understanding why I'll even need Data's lock(), unlock(), and
    isLocked() methods.
    The singleton business logic class has the synchronized book() method which uses one
    Data class and in English it will look something like this:

    Again, the above is a rough English representation of the booking method,
    for instance, there may be processing steps not shown which actually
    extract the clientIdBookingField or request to read it specificallly, all of these
    little steps are implied.
    Here are my Java concepts I'm applying (and, perhaps, if the above pseudo-code
    is not at fault, perhaps my concepts are):
    Two unique representatives are using the client software and through RMI are
    talking to my unique server which alone has access to the database file.
    My server and my database file exist on the same machine, any inbetween
    software between my server and the database file run within the same JVM.
    These two unique clients access my server simultaneously (and let's assume
    that my server is (I can only wish) running on a Mac G5 with dual processors,
    so they really are running at exactly the same time within the server's code
    as two unique threads.
    However, there is only one businessLogic class as it is a singleton; my server
    instantiated it as a singleton; and, all
    its public methods are synchronized. So, only one client thread will be able
    to enter it at a time. And, the client thread that enters the book() method
    first, will be the first one to see that no one has booked a particular record
    of interest, and then it will book it, while the next client thread to come in,
    will read the same record, see that it has been booked, and then tell the
    client that the room is no longer available.
    Thus, unless there is something which my limited experience simply refuses
    to see or my lack of Java experience on this issue doesn't allow to register
    with me, my design will allow only one client to write its client ID to any
    physical record in the file. And this is done without doing anything fancy,
    such as associating client ID's with record numbers in a Map; that is,
    the locking and unlocking scheme is controlled only by two factors:
    1. my design, and 2. reliance on the Java language feature of synchronizing
    the methods of a singleton class.
    Thanks,
    Javini Javono
    [Andrew: Added some ubb code tags]
    [ January 01, 2004: Message edited by: Andrew Monkhouse ]
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11525
        
    100

    Hi Javini,
    As you can see, I have edited your post. Your post now includes:
  • Some text in bold (bold text is between [b] and [/b] tags)
  • A code block which preserves your indentation and uses a fixed font (code blocks are put between [code] and [/code] tags)
  • A link to another URL (links to other URLS can be put in as a plain link (e.g. http://www.javaranch.com or can be put inside [url=url]descriptive name[/url] tags, so that [url=http://www.javaranch.com/]JavaRanch[/url] would appear as JavaRanch))


  • All these tags are described in the UBB Code page.
    Most of them can also be created quickly and easily when you edit your posts. There are buttons just below the edit box which will make it easy for you to put these tags into your post - note that it always adds them to the end of your post, so if you are creating your post in another editor then copying and pasting it into the edit box, you may find that you will have to move them around.
    I would recommend you edit your post above (the one that I just edited) and take a look at how I used those tags in your post. Each post has a line similar to the following on it:
    posted January 01, 2004 06:23 AM

    If you click on the icon for one of your posts you will be able to edit it. Try it - take a look at what I changed in your post .
    You may also be interested in trying the link - this will open a "post a reply" window with most of the original poster's message quoted for you already. This may be helpful.
    Note that I have not included a quotation block in your post. Although it can make posts more readable, there is a bug with UBB which can make text dissapear when you edit a post which contains both [code] and [quote] tags (this is why you never see Jim use [quote] blocks). If you are aware of this problem you can work around it, but if you aren't aware of it then you can suddenly find half your post disapears when you edit it.
    Regards, Andrew
    [ January 01, 2004: Message edited by: Andrew Monkhouse ]
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11525
        
    100

    Hi Javini,
    I think your code will work, and as you have noted it does not need the lock methods.
    The only problem with this concept is that you have created a bottleneck in a place where no bottleneck is required. Consider a simple case:

    Not too bad: there is a bottleneck, but it wont cause too much concern.
    But lets consider a future enhancement to the business logic. We want to calculate exchange rates at the time of booking (to get the most favourable exchange rate), which has to be calculated on number of beds requested:

    Hmmm - clients are blocked for longer now. The second client has to wait until the first client has finished all that work before they have any chance of finding out if the record is still available.
    Lets stop that method from being synchronized, and use some locking, and see what happens:

    See all those simulatenous lines of code? We have reduced the bottleneck.
    Also - your entire concept requires the book() method to be on the server - it cannot be moved over to the client without a major rewrite of all your code. You might want to take a look at the topic " Should lock methods be callable by the client" to see why I and others believe that the client should be calling lock() directly (others disagree (which is why Phil acknowledged that I can be wrong ) but you can make up your own mind).
    Regards, Andrew
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi,
    Thanks for your response. I'll study the referenced link topic discussion.
    Thanks,
    Javini Javono
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Andrew and Javini,
    Andrew:
    Also - your entire concept requires the book() method to be on the server.

    I didn't notice in Javini's post above (maybe I read it too fast ) that his book() method was on the server. Of course it's OK if the whole book operations sequences are serialized (including reads).
    Javini:
    Thanks for your response. I'll study the referenced link topic discussion.

    Good luck ! (this thread is ashamedly huge !)
    Best,
    Phil.
    Nicholas Cheung
    Ranch Hand

    Joined: Nov 07, 2003
    Posts: 4982
    Hi all,
    Just a little bit extention for Andrew's example.
    The 1st two examples are regarded as Serial execution schedules.
    Serial means transactions are executed one by one. (there is no interchange)
    In transaction processing theory, since we assume the programs are correct, i.e. a single thread transaction will always change the state of a DB from one consistent state to another consistent state.
    For the 3rd example, since the 2 transactions are operated on different records, if we apply serial transaction, it will degrade the performance much. Thus, transaction processing theory introduces a new concept, namely Serializability theory, which means that how can two or more concurrent transactions can be scheduled, so that the effect of the results will be equivalent to executing them in serial order.
    In the 3rd example, since they are not operated in the same data object, and thus, no matter how the threads execute, there is no problem.
    Even if the 2 transactions operate in the same data object, as we apply locking (if programming it correctly), the DB state will still be consistent.
    What I am going to say is, although the assignment does not require us to implement the database file in the DB manner, we still need to observe the DB theory (via locking).
    Hope that you feel these concepts interesting.
    Nick.


    SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi,
    Okay, I've gotten to the article (an article that I had glanced at in the past,
    but I didn't really understand it, because it takes numerous reads of my
    URLybird version 1.3.1 task before I start to understand the original
    document).
    Thanks very much for pointing me to this important 4 page web article.
    I admit that I am now resting, having only just read the first page; but,
    I'll eventually read all four pages.
    It is reassuring that I am not the only person parsing Sun's requirements!
    I wasn't sure if I was some weird langauge lawyer or not.
    I am quite happy that my assignment does not pass in a cookie to my lock
    method. And, as I don't have such an assignment, it would be silly for me
    to comment on this form of cookie use, but I can't help myself: the cookie
    can simply be a hash value for the current thread? i.e., if it's true that
    I don't even need lock and unlock, then for those with a cookie assignment
    don't need lock and unlock either. But, I don't have a cookie assignment, so
    it takes less courage to trivially implement (i.e., don't use, lock, unlock).
    In general, Sun's documents are so ambiguous, that what probably happens
    is that people bring their experience to their reading; so, for me, it never
    even occurred to me to expose lock and unlock to the client; I would never
    do this in real life, and I never even considered it as something Sun even
    requested; so, I certainly have no intention whatsoever of exposing lock
    and unlock to the client (bad idea, bad design, no way).
    This thread began, because I was curious if I would be automatically failed
    if I only trivially implement lock(), unlock(), and isLocked(), as they are not
    needed at all for my server to keep the database file from being corrupted.
    I think the best advice, nomatter what anyone does, is to justify it. And,
    probably, you should justify what you do, even if you think that it requires
    no justification because it is standard practice.
    So, while one could be a language lawyer with Sun's specifications to perhaps
    justify a trivial implementation of lock, unlock; it is probably safer to justify
    why they are not needed at this time (for instance, if you update to a JDBC
    database, why should your Java system be concerned with lock and unlock).
    Anyway, the remaining section of this particular post uses language lawyer "skills"
    to suggest why you may not need to implement a full lock and unlock scheme
    (but I would not present these to Sun, instead I would present arguments and
    reasoning for why I did what I did, not quibble over syntax):
    1. It's a must requirement to implement DBMain in Data; but, the Java programming
    language allows an implementation of a Java interface to be an empty method:
    public void lock() {}
    and thus, as far as meeting the requirements, it's implemented.
    2. "Server: Locking: 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, specifications
    and implementations are two different things (again, I'm being a language
    lawyer here): the interface specifies what must be done, the implementation are
    empty methods; and, my design implements the locking using synchronized
    methods in my BusinessRequests class.
    I did not say that very clearly, so here is another attempt:
    The DBMain interface states the intention of the server. I satisfy the intention
    of the server even though, paradoxically, lock and unlock are trivially implemented.
    Because I keep my database file from being corrupted due to two elements:
    1. My overall design, and 2. Because my BusinessRequests class has its methods
    (such as book()) synchronized.
    Again, seeing the referenced post makes me feel much better in that I'm not the
    only one finding Sun's specifications very ambiguous. And, probably the best
    thing to do is not argue with Sun as a language lawyer, but to use your language
    lawyer skills while thinking things through, but justify your final design and
    implementation with accepted principles.
    This topic was the last big area of ambiguity that concerned me. Although I can
    always change my mind, I plan to justify to submit trivially implemented lock and
    unlock methods, and justify my answer to sun.
    Aside: concerning the main thrust of the arguments in the other thread, I would
    never expose lock and unlock methods to the client (if I didn't already mention
    that is passing above). But, this is not to say that there is a right or wrong way
    to read Sun's specs; but, for me anyway, I never considered Sun even remotely
    requesting that the client touch the lock and unlock methods (and this could
    very well be that my spec makes no mention of cookies in the lock and unlock
    methods--thank goodness).
    Thanks a lot for all your help and pointing me to your past articles. Again, just
    to see the tons of verbage, all the ambiguity that exists in this assignment, and
    that other people have struggled with this ambuity makes me start to feel more
    confident and daring; but will I be automatically flunked? Will I chicken out?
    Who knows. But thanks to all!
    Thanks,
    Javini Javono
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi,
    I forgot to mention the following based upon the great comments I received earlier above:
    1. Concerning record locking. I'm not counting out record locking entirely. But, my
    first implementation will be based on my simple design and with synchronized
    methods in my BusinessRequests class. If I do add other forms of locking (for instance,
    beyond those of synchronizing BusinessRequests, which is similar to having a servlet
    which only handles one thread at a time) then I will not be bound by feeling that it
    must be done within Data--so, I will determine at that later time, if at all, where it
    will be done (above or below Data, or in front of or behind Data, in the hierarchy).
    Thanks to all for explaining the benefits of locking as far as bottlenecks go, and for
    introducing me to some of the elementary theory on this topic.
    2. Concerning the point that book() only exists on the server. The GUI client sends
    in a conceptual "book" request to the server; the GUI client never directly talks to
    the database in my design. Again, this was discussed at great length in the referenced
    link to the 4 page web article.
    Thanks very much. I hope my writing is not too off-hand and brusk. For I am very
    grateful for your responses.
    And even though I may sound like I have made a final decision, your comments
    will be in my mind, and will be mulled over and considered, and thus you should
    not confuse my statements, which sound final, as actually meaning that anything
    I state really is final, for software development unfolds over time, and as I design
    things out, my views will evolve with my design.
    Thanks,
    Javini Javono
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi,
    I've completed the four-page article referenced above.
    Thanks for pointing it out to my attention.
    I'm glad I did not study it immediately, but became
    aware of it after doing most of my thinking on my own--
    a procedure I recommend to others. Which is not to
    be confused with asking questions here; asking questions
    here (even if the same questions were asked here a few months
    ago, or even if similar statements were made a few months
    ago) is a great way to think, and is probably encouraged
    in this news group.
    Thanks,
    Javini Javono
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11525
        
    100

    Hi Javini

    [Can] the cookie simply be a hash value for the current thread?

    I assume you are talking about clients calling the lock methods in this case. The problem with using the hash value of the current thread is that the RMI specification makes no guarantees about use / reuse of threads (in fact it is explicit that any usage of threads is acceptable). Therefore it is quite possible that two separate clients will happen to use the same thread to lock a record, in which case they will both get the same cookie. Or, for some strange implementation of RMI, all clients could get the same cookie for all lock requests. Also clients would still need to keep track of this cookie - there is no guarantee that the same thread will service their subsequent call to update().

    In general, Sun's documents are so ambiguous, that what probably happens
    is that people bring their experience to their reading; so, for me, it never even occurred to me to expose lock and unlock to the client; I would never do this in real life, and I never even considered it as something Sun even requested; so, I certainly have no intention whatsoever of exposing lock and unlock to the client (bad idea, bad design, no way).

    I can understand that. I came about that thread from another perspective: having done an earlier assignment where it was explicit that clients must be able to call lock, I then considered that to be normal in the new assignment, and got confused why everyone seemed to think that they could hide this from the client. I still believe that Sun's original intention was that clients should call locking (hence the cookies, and the instructions "the server provides..."), but I think that Sun have realised that there are ambiguities in the specification so they (currently) allow locking to be hidden.

    This thread began, because I was curious if I would be automatically failed
    if I only trivially implement lock(), unlock(), and isLocked(), as they are not needed at all for my server to keep the database file from being corrupted.

    You might also want to look at the topic "Why Is This Not Thread-Safe?". There are no definitve reasons why Aaron failed, but it is possible that it was a combination of trivially implementing lock(), and unlock(), and then not documenting what he did and why he did it adequately.

    1. It's a must requirement to implement DBMain in Data; but, the Java programming language allows an implementation of a Java interface to be an empty method:
    public void lock() {}
    and thus, as far as meeting the requirements, it's implemented.

    True, but what does your instructions state in the comments for the lock() method in the interface. Mine show the following:

    So it is clear (IMHO) that Sun expect the lock method to actually do some work.

    2. "Server: Locking: 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, specifications and implementations are two different things (again, I'm being a language lawyer here): the interface specifies what must be done, the implementation are empty methods; and, my design implements the locking using synchronized methods in my BusinessRequests class.

    I would read that differently. It is clear from another part of the instructions that you the Data class must implement the interface. And the server instructions state that the server must provide the same functionality as well. I think this is a reasonably standard request: you have a standard interface which multiple clients use, now you want to provide it over a different medium (in our case RMI, but it could be over SOAP or MQ), and you want to keep the same interface.

    The DBMain interface states the intention of the server.

    Yes, but that is not it's primary purpose. It's primary purpose is to provide the contract which must be adhered to by the Data class.
    Do you have the instructions "Portions of your submission will be analyzed by software; where a specific spelling or structure is required, even a slight deviation could result in automatic failure.". There are two places where I could see such software analysis occuring: on the Data class (which has to implement a specified interface), and potentially as a client connecting to the server (if you have the DBMain methods callable over the network). In reality I think only testing of the Data class can be done programattically, and even then it can only be done after the examiner has looked at your code. But assuming that the examiner does run the automatic tests. If they run it on your Data class they will find that two threads can "apparently" lock the same record simultaneously. And they cannot run the automatic tests against your server since you are hiding the locking functionality.

    And, probably the best thing to do is not argue with Sun as a language lawyer, but to use your language lawyer skills while thinking things through, but justify your final design and implementation with accepted principles.

    Yes, justification is the big thing. Spend a lot of time making sure that it is explicit what you are doing and why.
    Regards, Andrew
    [ January 02, 2004: Message edited by: Andrew Monkhouse ]
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Javini,
    Sorry for yesterday, but I really didn't have the time (I had a very important job interview to prepare) to read you better than "in diagonal" (mmh... I could nearly write "in vertical" as your threads count many words OOH and look formatted as if you wrote them on toilet paper What the heck do you use as an editor ?! ).
    Anyway, I'll now read *every* word, post after post. And this is a reply to the first one.
    When you write (bold words were put in bold by myself) :
    Okay, I knew I left something out; here are Sun's supplied
    comments for these three methods as found in the
    DBMain Java interface code:
    lock(): "Locks a record so that it can only be updated or deleted
    by this client. ..."
    Well, what is "this client" mean; if my threads are controlled, I don't
    care exactly which client "this client" is, right?
    unlock(): "Releases the lock on a record."
    isLocked(): "Determines if a record is currently locked. ..."
    So, in conclusion, I see nothing in my particular specifications
    which mandates that locking a record and associating this
    lock to a specific client is required. If this assertion is true,
    then perhaps I've gotten an easier version of the assignment
    than other postings I've seen here.

    Your reasoning would be OK if you didn't play with words as you do, mixing their meanings.
    "my threads are controlled" is specific to your implementation of the whole app.
    "I see nothing in my particular specifications" should have been written "I see nothing in my particular implementation".
    The provided DBAccess interface, include locking, is part of SUN's specifications. And, at the db level, implementing their specs is a *must* (no read to recall you what "must" means in this assignment).
    Now if this particular application lets you implement a global solution which doesn't need *all* DBAccess functionalities (BTW it's obvious for create() and delete() at least), does it mean that you don't need implement the whole DBAccess stuff as stated ?
    multiple clients use the server, and
    multithreaded remote method of server invokes
    singleton DataManager methods with each business method (such as "book()") synchronized
    which in turn uses Data
    which in turn uses a RandomAccessFile
    which in turn uses a physical random access file.

    Now let's agree on the fact that your implementation doesn't need db locking. It's only true because you serialize all client accesses (one and only one "transactional" access per client at a given time). But by doing so, don't you think that you transgess a second "must" ?

    "Locking: 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."
    Are your client requests - even partly - ever concurrent ?
    Except for the one must condition that I implement the
    DBMain Java interface, in which case I need to implement
    lock(), unlock(), and isLocked() even though to do so would,
    it appears to me, be completely silly given my design.

    Silly ? Implementing any interface means fulfilling a contract. If you don't need a part of this contract, other people may need it and anyway ... half the work you *must* do in this assignment (and upon which you'll be graded ) is implementing DBAccess. Here is a discussion about interfaces seen as contracts.
    Javini, this was my answer to post 1. I'll now read the next ones in detail too...
    Best,
    Phil.
    [ January 03, 2004: Message edited by: Philippe Maquet ]
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Javini,
    About your second post (posted December 31, 2003 08:49 PM), I've nothing to add : you're still mixing SUN's specs (your "must-do") with your needs as an application developer.
    In comparison, my db package can be put as it is in any context and still work as described in the DBAccess specs. Whatever you choose *outside* of the db package (stand-alone app / networked with RMI / networked with sockets / locking handled client-side or locking handled server-side) it ... still works.
    Regards,
    Phil.
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Javini,
    I now read what Andrew wrote later in this thread :
    I would read that differently. It is clear from another part of the instructions that you the Data class must implement the interface. And the server instructions state that the server must provide the same functionality as well. I think this is a reasonably standard request: you have a standard interface which multiple clients use, now you want to provide it over a different medium (in our case RMI, but it could be over SOAP or MQ), and you want to keep the same interface.

    And you guess that I agree .
    Do you have the instructions "Portions of your submission will be analyzed by software; where a specific spelling or structure is required, even a slight deviation could result in automatic failure.".

    I'll transform Andrew's question in my own assertion : if you *really* do what you described above, you won't "risk" an automatic failure, you'll get it for sure.
    Yes, justification is the big thing. Spend a lot of time making sure that it is explicit what you are doing and why.

    I'll give you the opposite advice. I think you have a words/arguments ratio which is far too high. Just think that your grader possibly will be short of time when he'll have to read you choices.txt file. So the more ideas/arguments you'll put in it in the least possible number of words, the best chance you'll get that he'll read and understand everything (IMO ).
    Regards,
    Phil.
    [ January 03, 2004: Message edited by: Philippe Maquet ]
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi,
    Thank you all for your responses. Due to the holiday weekend with family
    guests and visiting, I have not had time to dedicate enough thinking and
    understanding at this time to absorb, think, and respond to your remarks
    in a responsible manner. And, even if I had time, it can take multiple
    readings, and having ideas ferment in my head before something clicks
    and I have a responsible response or idea.
    Keep in mind that these are very initial responses of mine here; more
    responsible responses require reading your posts at least three times over
    three different occasions, taking notes, reviewing my ideas and yours,
    and the like.
    Please let it be noted that I am open to persuasion, and I'm quite happy
    to get hard, honest replies from all of you. I particular like the phrase which
    went something like this: "the probability of you failing is not likely, it's
    assured." A small joke I thought of today was, given that some books
    talk about "lazy programmers" to justify interesting design patterns, was,
    "am I that lazy that I'd risk failure." Okay, it's not that funny, but it's a
    joke which I came across in my head which made me giggle slightly.
    Concerning the Java interface DBMain. It has been suggested that DBMain
    is a contract. However, I am the first person in this company to work on
    a Java project; assume that there are things about DBMain that I don't
    like; well, in the real world I will not propagage a bad interface, for doing
    so implicitly creates a bad contract (assuming that DBMain is not up
    to snuff, which I believe at this time). That is, if I personally embrace DBMain
    I am participating in what I believe to be irresponible behavior. But,
    if I hide Data which implements DBMain, don't let anyone in the future
    every instantiate, I am saying, "this contract simply is not up to what I expect
    from a responsible interface; yes, I'll use it to satisfy Sun, but no one else
    will; on top of Data I'll build DataFace, it will through exceptions, for instance,
    as they should be thrown, including standard I/O Exceptions; it will eat
    no exceptions, and the like."
    If anyone in the company instantiates DBMain instead of requesting a
    sub-class of DBMain from the factory, they are violating my assertion
    that DBMain is _not_ going to be a contract in this company.
    If anyone has a reference to DBMain and calls any of its methods, and
    DBMain is a reference to exactly a DBMain object and not to one of
    DBMain's subclasses, an exception will be thrown: IllegalUseOfDBMainClassPleaseUseFactoryyInstead.
    Okay, sorry for being long winded. Now for the next point: this point
    said that no part of my server was multithreaded. While it is true that
    for my initial, "lazy" design (i.e., where lock() and unlock() are irrelevant),
    (where "lazy" refers jokingly to me being a lazy programmer), is not
    multi-threaded with respect to the database file being read or written,
    all other parts of the server are multi-threaded. Thus, you have this:
    1. The server accepts commands from the multiple clients: multithreaded.
    2. The server operates through a sub-class of DBMain to read and write
    the database file: not multithreaded, but the file can't be corrupted.
    3. The server packages the response to send back to the client: multithreaded.
    I apologize for not being able to spend time to give you all a more detailed
    response. At this time, over the holidays, I have offered broad, sweeping
    comments which are more philosophical in nature; that is, they state my
    philosophy which motivates my actions.
    One more minor philosophical point: my initial feeling, intuitive, if you will,
    is that locking and unlocking should not be in DBMain; it is a separate
    concept, a separate responsibility from that of reading and writing. This
    I would consider an additional design flaw in DBMain, and it would be
    irresonsible for me to make a presumably faulty design a contract by
    me being the first developer in this company to legitimatize this Java
    interface by implementing it. If locking and unlocking occur, they would
    occur in another class either above, below, in front of, or behind Data.
    Again, I have not implemented locking and unlocking, but my preliminary
    intuition, is that locking and unlocking don't belong in DBMain, and if
    this preliminary intuition is found to be generally agree upon by responsible
    and experienced developers, then it is my responsibility _not_ to put
    lock and unlock in DBMain which propogates into the future a less than
    ideal Java interface. But, this is just intuition, and like the faulty
    exceptions in DBMain, just another example of my philosophy: if the
    interface is bad, I don't want to irresponsibly make it a contract by
    implementing it.
    Happy holidays. And, again, your comments are very important to me.
    You are very kind.
    Thanks,
    Javini Javono
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi,
    Corrections:
    the following:
    *******************************************************
    If anyone in the company instantiates DBMain instead of requesting a
    sub-class of DBMain from the factory, they are violating my assertion
    that DBMain is _not_ going to be a contract in this company.
    If anyone has a reference to DBMain and calls any of its methods, and
    DBMain is a reference to exactly a DBMain object and not to one of
    DBMain's subclasses, an exception will be thrown: IllegalUseOfDBMainClassPleaseUseFactoryyInstead.
    *******************************************************
    Should read:
    *******************************************************
    If anyone in the company instantiates Data instead of requesting a
    sub-class of Data from the factory, they are violating my assertion
    that Data is _not_ going to be a contract in this company.
    If anyone has a reference to If anyone in the company instantiates DBMain instead of requesting a
    sub-class of DBMain from the factory, they are violating my assertion
    that DBMain is _not_ going to be a contract in this company.
    If anyone has a reference to Data and calls any of its methods, and
    it is a reference to exactly a Data object and not to one of
    Data's subclasses, an exception will be thrown: IllegalUseOfDBMainClassPleaseUseFactoryyInstead
    *******************************************************
    Aside: Whether future client programmers will say:
    Data data = AbstractDataFactory.create();
    or
    DBMainEnhanced data = DBMainFactory.create();
    I have not decided yet, as I am still organizing
    how things will be done. That is, will the client
    programmer hold a reference to an class or
    an interface.
    Thanks,
    Javini Javono
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Originally posted by Andrew Monkhouse:
    Hi Javini,
    I think your code will work, and as you have noted it does not need the lock methods.
    The only problem with this concept is that you have created a bottleneck in a place where no bottleneck is required. Consider a simple case:
    ...lines deleted...
    But lets consider a future enhancement to the business logic. We want to calculate exchange rates at the time of booking (to get the most favourable exchange rate), which has to be calculated on number of beds requested:
    ..lines deleted...

    Hmmm - clients are blocked for longer now. The second client has to wait until the first client has finished all that work before they have any chance of finding out if the record is still available.
    Lets stop that method from being synchronized, and use some locking, and see what happens:

    See all those simulatenous lines of code? We have reduced the bottleneck.
    Regards, Andrew

    Hi,
    I have used the facilities at this site to quote some aspects
    of your original reply; but, I have also removed some lines
    for compactness.
    At some point, something has to be synchronized and thus there
    has to be a potential bottle neck somewhere. Let us take your
    example where some extensive CPU calculation might occur in
    the future:
    Current atomic, single threaded opeation:
    Read record i.
    Perform long computation on record i's field j.
    Update record i's field j.
    Let us assume that this long computation creates too much
    of a delay for other clients waiting to access the DB file;
    thus, we have defined a real bottle neck situation that needs
    to be addressed.
    Using the ideas of my design already spoken of wherein lock()
    and unlock() are not used, you remove the bottleneck with
    the following conceptual approach:
    Atomic, single threaded step:
    Read record i.
    Multithreaded step not requiring any form of "lock" on the
    DB file or any single threaded processing:
    Perform long processing on record i's field j.
    Atomic, single threade step:
    Read record i to ensure that it has not changed (if it has,
    take special action).
    Update record i.
    Therefore, the long computation no longer creates a bottleneck.
    The above are concepts, not implementaiton details. Of course,
    if the above concepts can't be implemented, then that's
    another story altogether. (For instance, I saw a movie about
    a movie script writer who wrote a movie about a man with a split
    personality who was both a police man and a serial killer; the
    joke of the movie was that this conceptual idea could not actually
    be implemented; thus, a concept is one thing, being able to make
    it work is another).
    Thanks for pointing out bottlenecks to me, and if the above
    conceptual idea I have stated just now is sound, I will consider
    if I my design will easily allow the future enhancement wherein
    a long computation might occur after a read.
    Does the above conceptual idea seem sound?
    Thanks,
    Javini Javono
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi Andrew,
    This short response answers one of your questions
    specifically:
    *************************************************
    True, but what does your instructions state in the
    comments for the lock() method in the interface.
    Mine show the following:
    **************************************************
    Mine has no return type thus:
    public void lock(int recNo) throws RecordNotFoundException;
    And
    "" Thus, in my
    opinion, (and I repeat myself in that I've said this above),
    there is no extant Java codebase, and thus no existing
    code nor any reason to assume that any future code must use
    the DBMain interface. If I do code to this interface and
    make it available to future applications, then I am potentially
    irresponsible for this harnesses the company to use this poor
    DBMain interface far into the future perhaps.
    Required Interface: "".
    Thus, Data can trivially implement it thus:
    public void lock(int recNo) throws RecordNotFoundException {
    }
    For the above is an implementation as far as the compiler is
    concerned.
    Finally, it says, ""
    So, my server does provide for handling of multiple concurrent
    requests (let's assume), but when it comes time to carry out
    short reads and writes to the database file, this one part of
    the server is single threaded.
    The just above quoted paragraph, states what my server must do,
    and what it must do is stated as documentation comments to the
    lock() and unlock() methods. My server does this without needing
    the lock() and unlock() methods.
    So far, I've repeated myself, and people have responded to my
    initial comments.
    There is one response above to my ideas which goes something like this:
    the documentation comments for the lock() method are now inaccurate,
    in that your lock() method does not lock anything at all, it does
    nothing.
    This is an excellent point. Thus, I will use JavaDoc to deprecate
    this method.
    Again, what I will actually do is never known, but this is my
    plan _at this time_ (and I can always change my mind).
    Thanks,
    Javini Javono
    [ January 07, 2004: Message edited by: Javini Javono ]
    Javini Javono
    Ranch Hand

    Joined: Dec 03, 2003
    Posts: 286
    Hi Andrew,
    Andrew: Quoted Segment*************************************************
    Do you have the instructions "Portions of your submission will be analyzed by software; where a specific spelling or structure is required, even a slight deviation could result in automatic failure.". There are two places where I could see such software analysis occuring: on the Data class (which has to implement a specified interface), and potentially as a client connecting to the server (if you have the DBMain methods callable over the network). In reality I think only testing of the Data class can be done programattically, and even then it can only be done after the examiner has looked at your code. But assuming that the examiner does run the automatic tests. If they run it on your Data class they will find that two threads can "apparently" lock the same record simultaneously. And they cannot run the automatic tests against your server since you are hiding the locking functionality.
    **********************************************************
    I realize that peoples comments and responses, often do not necesitate
    a response on my part. Thus, I hope that I am not being argumentative,
    as this is not my intention. But, if people take the time to respond
    to my initial comments and questions, then it is probably appropriate
    for me to respond to those responses; and, I sincerely hope that
    my secondary responses, such as the one to follow, are not seen as
    argumentative.
    My requirements state: "".
    Let it be assumed that Sun intends to look at my code, and write
    a test harness to test my server. The way my server is designed,
    you would never test it by writing a test harness which directly
    and specifically targets the Data.class directly, but instead
    "talk to my server" through the business methods it exposes as a
    public interface.
    There is nothing in the requirements which says where "Data.java"
    must be in the hierarchy of classes. In my design, it is considered
    a bad interface due, if for no other reasons, to its inability to
    throw appropriate exceptions; thus, it is "buried" at a low level
    and more client-programmer-friendly classes, such as JavaFace are
    what the client programmers use.
    If Sun were to write its own test harness (which, if you think about
    it, is not exactly "automated" since the first step involves coding),
    they would have to read the JavaDoc which would state that it is
    illegal to directly instantiate Data without going through a factory,
    that lock(), unlock(), and isLocked() are deprecated, and that
    attempting to instantiate exactly a Data object without going through
    a factory and then calling its methods will result in an illegal
    usage exception.
    I'm not being argumentative, I hope; but, I guess I'm essentially
    saying that if Sun attempts to write a test harness for Data, they
    are not following my directions which is that Data's interface is
    not up to snuff, is not to be used, and instead client programmers
    are to use DataFace class instead.
    The only reason that Data even exists, is because it is a must condition;
    but, every tool and concept is being used to drive Data into oblivion
    so that the company does not commit itself to a bad contract (i.e.,
    dos not commit itself to having to code to a bad Java interface
    in the future).
    Thanks,
    Javini Javono
    [ January 08, 2004: Message edited by: Javini Javono ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: NX: Locking and Unlocking and Sun's Must Conditions