The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
posted January 01, 2004 06:23 AM
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew:
Also - your entire concept requires the book() method to be on the server.
Javini:
Thanks for your response. I'll study the referenced link topic discussion.
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)
[Can] the cookie simply be a hash value for the current thread?
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.
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.
The DBMain interface states the intention of the server.
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.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
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.
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.
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.
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.
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.".
Yes, justification is the big thing. Spend a lot of time making sure that it is explicit what you are doing and why.
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
Aaaaaand ... we're on the march. Stylin. Get with it tiny ad.
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|