NX: Locking and Unlocking and Sun's Must Conditions

[Javini Javono]

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]

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]

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

[Javini Javono]

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:

public synchronized void book(physicalRecordNumber, uniqueClientId)
   throws RoomAlreadyBookedException {
   
   String clientIdBookingField = data.read(physicalRecordNumber);
   if (clientIdBookingField == all blanks) {
      //The room is not booked, so book it.
      data.update(physicalRecordNumber, field with uniqueClientId);
   } else {
      throw RoomAlreadyBookedException("...");
   }
}

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]

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]

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:

  Client A             Client B
  ================     ================
  readRecord(5)
  if available
      updateRecord
  endif
                       readRecord(4)
                       if available
                           updateRecord
                       endif

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:

  Client A             Client B
  ================     ================
  readRecord(5)
  if available
      getExchangeRate
      calculatePrice
      updateRecord
  endif
                       readRecord(4)
                       if available
                           getExchangeRate
                           calculatePrice
                           updateRecord
                       endif

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:

  Client A             Client B
  ================     ================
  lockRecord(5)
                       lockRecord(4)
  readRecord(5)
                       readRecord(4)
  if available         if available
      getExchangeRate      getExchangeRate
      calculatePrice       calculatePrice
      updateRecord         updateRecord
  endif                endif
  unlockRecord(5)
                       unlockRecord(4)

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]

Hi,
Thanks for your response. I'll study the referenced link topic discussion.
Thanks,
Javini Javono

[Philippe Maquet]

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]

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.

[Javini Javono]

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]

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]

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]

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:

// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lock(int recNo) throws RecordNotFoundException;

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]

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]

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]

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]

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]

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]

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:

  Client A             Client B
  ================     ================
  lockRecord(5)
                       lockRecord(4)
  readRecord(5)
                       readRecord(4)
  if available         if available
      getExchangeRate      getExchangeRate
      calculatePrice       calculatePrice
      updateRecord         updateRecord
  endif                endif
  unlockRecord(5)
                       unlockRecord(4)

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]

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]

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 ]