Aaron Parsons

+ Follow
since Apr 03, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Aaron Parsons

Cheers Roel,

That was exactly what I wanted to hear... Have documented decisions thoroughly...

Just one more thing...

4. Requirement: 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.

I think I'm confusing myself the more I think this over.

Does ....

"or for records where the name and/or location fields exactly match values specified by the user" ....

mean: for a search result to be returned the search criteria must exactly match the record field? i.e: In order to return the Hotel California record, the user must search for 'Hotel California'.

or does it mean: for a search result to be returned the record criteria can partially contain the search criteria? ie: Hotel California record is return from search criteria 'Hotel', or 'California', or 'otel', or 'a'... etc.

I have implemented the second interpretation but I'm now aligning myself with the first one? In which case why do they state in the beginning of the project brief...

'The following are the "top level" features that must be implemented:

A client program with a graphical user interface that connects to the database
A data access system that provides record locking and a flexible search mechanism
Network server functionality for the database system'

... when a search mechanism based on the first interpretation is not really that flexible
Hi guys,

I am right at the end of the URLyBIRD assignment and am cross referencing my work with all of the MUST requirements before packaging and submission... I am slightly concerned with a particular MUST requirement which I thought I'd share with you for some advice...

1. Requirement: It must allow the user to book a selected record, updating the database file accordingly.

I have thus far implemented a record caching structure, which only writes back to file on termination of the program (shutdown hook in Data class). Do you think I would fail the above must requirement as I am not updating the database file every time a client books a hotel record?

2. Requirement: Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface: [DBAccess]

I have extended the DBAccess interface and added a method getAllRecords() to speed up the system. Are extensions OK in light of the above requirement?

3. Requirement: You must use RMI over JRMP (do not use IIOP).

Does the standard default RMI mechanism adhere to the above requirement?


Ok hello all, my name's Aaron, and this is my first post on this forum!

My interest in programming started when I attempted to design a system to aid in trading systems (about a year ago). My knowledge has literally started from the ground up. While my knowledge base has grown, so has my realisation of what I don't know (which would make me a wise man according to socrates). I started learning the basics, writing small programs, games etc. I was thinking to my self, while I'm learning this stuff wouldn't it be nice to have something to show for it - hence my desire to complete the SCJP. I bought Kathy and Bert's SCJP study guide, and read! Wow, what a great overview of programming concepts in general. I realised that up to the point of reading the book I had been doing everything the 'hard' way so to speak (tackling my own 'collection' management system, my own serialization, etc). Now since studying the book I realise just how little I know overall, and sometimes I confuse myself with certain concepts. I know that given time these concepts will be drilled in. And this brings me to the topic of my first post; Threads.

I don't if anyone would agree with the statement; Threads are hard for beginners to visualise, espec. synchronization (locks, monitors)!! If you do, then please read on and try to help me if you can...

My problem specifically relates to an example in the text above, Kathy and Bert's SCJP study guide. You can find the example on pages 754 -755. I'm not sure if I am allowed to copy the text for publishing issues but anyway, this is a rough picture..

A couple of pages before, an outline of a system is proposed.
Within this system there is a user, and a machine.
The user selects shapes. The machine makes the shape.
The user has to send the shapes to the machine, using some software interaction.
It is proposed that the best solution is via Thread interaction. WHY? Because then the user can still continue to select shapes while the machine does its bit.

While the example mainly tries to tackle the importance of the wait(), and notify() methods, as well as iterating the point that for sound coding the wait() method should be placed within a while(...) loop to continually check the wait conditions... my point is more related to the overall design of the system. Bare with me please guys and girls...

Going over the code in the book, I argue that the system proposed, or rather the design approach would only allow the user to select a maximum of one other shape while the machine is processing the code, and not MULTIPLE shapes! Maybe i'm missing something here, but it seems that if both user and machine classes have code that synchronises with the 'list of things to do'... then while 'things are added' the 'machine cannot access the list', and while 'the machine is using the list' 'things cannot be added'. simple synchronisation right? if for example, the machine class just sends the hardware instructions and that takes less time that it does for the user to select the shape then in reality there's no problem. BUT, theoretically speaking, is my thinking right? if the machine class sends the hardware instructions within the synchronised code then there could never ever be more than one instruction, right? or wrong?

Thanks for reading.