I'm bit confused about the information provided in the instruction.html file. The following line below is taken from the document:
The user interface for this assignment must satisfy the following criteria: It must be composed exclusively with components from the Java Foundation Classes (Swing components). It must allow the user to search the data for all records or for records where the name and/or location fields exactly match values specified by the user. It must present search results in a JTable. It must allow the user to book a selected record, updating the database file accordingly.
When I look at the interface that is provided by Sun. It provides the following methods:
The confusion thing is that the document doesn't say anything providing the functionality for deleting and creating record, but interface suggest implementing the methods above.
How can I interpret this - I provide the implementation but do not provide the functionality in my GUI or can I leave these methods empty in my Data.java class?
[Andrew: Moved quotation inside quote tags] [ May 23, 2006: Message edited by: Andrew Monkhouse ]
Actually, I'm confused as well. I did not order the assignment (I did not even pass the SCJP!), and trying to see if I can do this (it cost $250!) before ordering it.
So, we have a database D with records R1, R2, ..., Rn. The server is the only one that can write/read from D. The server receives a request from client over the Internet. A synchronised(D) methods executes and tries to lock the record (in case of write) Rx sent by the client. That means I need a unique lock for every record in D. After that, the thread servicing this request tries to finish the request.
This way, I can have concurrent access to the D (I can read records that are not locked as well as delete one record and update a different one at the same time). But, now wait a minute! Don't I need to synch on D when I actually write to the D?? Because if I don't, I can be interrupted between the seek() and the write().
I'm more confused now!
Jeroen T Wenting
posted 13 years ago
Where's the confusion? The locking system isn't meant to make synchronisation superfluous, it's implemented on a business logic level rather than a code logic level.
Since your post is not related to Ricky's topic, you should really create your own topic for your question. Doing so may help you get more responses (since not everyone will read a topic labeled "[B & S] Create and Delete Record"), and will help prevent Ricky's questions being lost in non-related chatter.
Can't we synchronize the update() method and ignore the lock() methods?
Why do we have lock() methods in the Data class?
Most of the file operations require some synchronization, as they involve accessing a single shared resource. Even worse, they often involve two operations on that single shared resource, where the two operations must behave atomically. That is, you would normally perform a seek() and then a write(), however you do not want any other thread to perform a seek() between when you performed your seek() and when you perform your write(), otherwise you will end up writing in the wrong location within the file.
(We will ignore for the moment the question of whether it is better to synchronize the entire update() method in Data class, or whether to just put the seek() and write() methods within a syncronized block.)
So having somehow synchronized the access to the file, we still have a problem of two clients believing that a record is available, and both trying to update it. That is:
Client A checks that record 5 is avaialable
Client B checks that record 5 is avaialable
Client A updates record 5 with their client number
Client B updates record 5 with their client number
now client B has overwritten client A's booking
This is where the logical record locking available through the lock() and unlock() methods of the Data class come in - in the above scenario, if client A had logically locked record 5 prior to checking availability, and client B had attempted to locally lock record 5 prior to checking availability, then client B would be blocked until client A had finished - no more problem.