Niall ORiordan

Hi Philipe,
Why is it that you insist that delete/update must not be available to the client?
The delete() and method in DBAccess will not be accessible unless you provide a GUI for it. (As no other method will delete a record as per spec.)
Also, if you leave out a GUI for delete and update then all you have left is create new and search and book. Is this what you are suggesting?
If so, the you suggest a very simplistic approach that I had not though of.
In my (submitted) assignmentI just used the schema to determine the look of my GUI and provided a very thin client that "used" all the methods in the DBAccess interface. And provided a JTable for search results. Do you think I will be penalised for providing an explicit update and a delete function?

Hi all,
I can see why you guys prefer RandomAccessFile to the DataOutputStream and DataInputStream classes for I/O to/from a file. However, if you are using RandomAccessFile I reckon you are making the assumption that you are changing the actual database file in real time. In other words you are reading and writing to the datbase with EVERY operation on the database. However, I looked at it from a different angle and read the database into an internal representation. Therefore, there was no need to read the database every time you wanted to perform an operation on the database....you just do everything against this internal representation. Then I could commit the database to file after every update,delete operation in order to provide a kind of transactioning system....
What do you think?
Do you think RandomAccessFile solution is a 'cleaner' solution?

I have implemented the reading and writing of the DB with DataInputStream and DataOutputeStream as alluded to in the assignment (Bodgitt and Scarper.)
I works really well and is much easier that RandomAccessFile.
/Niall

Hi Vlad,
Can you post a reference to the thread you are referring to I have a similar problem and would like to read other peoples approcah to this.
Regards,
/Niall

Cheers Max,
I saw another post of yours regarding the same thing....And I see your point.
Thanks a million.

Hi all,
I was just thinking about the following scenario...
Thread 1 locks a record and straight away, the thread fails (for some unknown reason). Do I need to make sure that the locked records of this thread are released after the thread dies?
Or is this beyond the scope of the assignment?

Originally posted by Niall ORiordan:
No it is not possible as the StringIterator class is essentially a private variable in the outer class...therefore only instances of the outer class can use (and therefore modify) instances of the StringIterator
Regards,
/Niall

No it is not possible as the StringIterator class is essentially a private variable in the out class...therefore only instances of the outer class can use (and therefore modify) instances of the StringIterator
Regards,
/Niall

Not sure what the manifest file is. I would imagine it is something with do with Jarring of the jar file you downloaded...That is what manifest files do.
As for your other question....
Take a copy of the .dat file...
DO NOT USE THE ORIGINAL TO MEES AROUND WITH or you will have to download the assignment again. Otherwise feel free to do what you like. Good luck.

Hi Shilpa,
For Bodgitt and Scarper I found the DataOutputStream class very useful. This is of course if you are using a transactional system. It mentions this class in the assigment even.
/Niall

Thanks for the info guys.
Therefore I can assume to a certain extent that there will not be too much emphasis put on the threading capacity of your code. In other words, networking capaacity is a lower priority to actual implementation of locking and the avoidance of deadlock etc.
Also, What I have done is implement my code in such a way that a single client only locks a single record at any one time....performs the desired action on it and straight away unlocks this record. Therefore, there will never be a deadlock situation.
Many regards guys and thanks for all the info.
/Niall

Just a little bit of advice for you.
Why are you making all changes directly to the file?
Can you not think of a better way of making changes and storing the database?
File access is extremely slow and also very hard to make threadsafe..
Maybe you should reconsider your design from scratch?
Cheers,
/Niall

Does anyone ever fail the SCJD? I do not know anyone who has.
Also, I have managed to stress test my application using 100 concurrently created threads performing random accesses to the database.... Does anyone have a good idea as to "how threadsafe" an application should be....There are capacity issues with the network/HW I am using.
Cheers guys,
/Niall

Hi guys,
Cheers for the responses.
However the lines are simply meant to signify interface between classes (or a group of classes).
This is mean to portray an overall architecture of the SCJD not anything else.
Thanks,
/Niall

I have the following as an overall design.
Would anyone like to comment?
GUI
|
PROXY
/ \
CLIENTSOCKET CLIENTSTUB
| |
NETWORKSOCKET PROTOCOL
| |
PROTOCOL DATABASE_MODEL(IN JVM)
| |
DATABASE_MODEL(IN JVM) DATAFILE
|
DATAFILE
Every time a query is posted to the database that changes the contents (except for a lock/unlock) this change is commited to the DATAFILE.
What do you guys think?