Is this a bad way to approach things?

[Eric Chang]

I'm practically done with the local standalone version of my assignment, and unfortunately, I started thinking about my design decisions and having a few second thoughts. One of my decisions was to only read from the datafile upon opening up the client, and then maintaining the records in an ArrayList. And upon the updating of a record (deletion, creation, etc.), I would update the object in the ArrayList as well as update the data file at that time. And this ArrayList would obviously be maintained on the server.
Now, for some reason, I'm thinking that maybe it would have been better to always read from the datafile upon opening a record for updating, and not maintaining anything in an ArrayList at all. That would save me the trouble of hoping that the ArrayList and the datafile never get out of synch.
Any thoughts on the issue?
Also, another much more minor question...the Java Tutorial has a nice example of using SpringLayout, with an accompanying SpringUtilities.java for layout out components...what would be the pros and cons with using that code example?

[peter wooster]

Originally posted by Eric Chang:
I'm practically done with the local standalone version of my assignment, and unfortunately, I started thinking about my design decisions and having a few second thoughts. One of my decisions was to only read from the datafile upon opening up the client, and then maintaining the records in an ArrayList. And upon the updating of a record (deletion, creation, etc.), I would update the object in the ArrayList as well as update the data file at that time. And this ArrayList would obviously be maintained on the server.
Now, for some reason, I'm thinking that maybe it would have been better to always read from the datafile upon opening a record for updating, and not maintaining anything in an ArrayList at all. That would save me the trouble of hoping that the ArrayList and the datafile never get out of synch.
Any thoughts on the issue?
Also, another much more minor question...the Java Tutorial has a nice example of using SpringLayout, with an accompanying SpringUtilities.java for layout out components...what would be the pros and cons with using that code example?

Caching all the records:

Lots of people have done this, it makes some parts of the code easier, but complicates others. I simply use a RandomAccessFile and let the operating system do the caching, its likely to be way better than anything I can code up.

SpringLayout:

I use this layout, but I don't use SpringUtilities because I'm not sure if its permitted as its not part of the JDK and I didn't write it. You can build a very nice form using SpringLayout that is a lot simpler than the more general code in SpringUtilities.

[Nicholas Cheung]

You should not use any other utilities or classes that are NOT come along with J2SE package.

Nick

[David Abramowicz]

Regarding "only initial read to datastore file".

I also only read the file on startup of the server.

For every modification I write to the file again, but I never perform another read. This is clearly stated in the userguide.txt

I consider this a viable approach, as from what I understand it is stated in the instructions that you only need to account for ONE server, so there will never be any complications.

If anyone disagrees with this theory please let me know

/Dave

[Nicholas Cheung]

For every modification I write to the file again, but I never perform another read. This is clearly stated in the userguide.txt

This might lead to the issue for violating the serializability theroy. Remember, you must make sure that the data should be consisent for all clients. In addition, there is only one server is not equivalent to there is only 1 client interact with the system.

If you dont read the file again, how could you check for the update? For example, user A books hotel 1 at time X, while user B did the same. In your case, you only perform a write, and thus, the transaction of B will overwrite that of A.

If you store the data in, say, cache for performance issue, you need to make sure that both values, in file and cache, are updated, or both undo if either or both updates fail, otherwise, there will be inconsisency.

Of course, you might document the "features" of your system, however, if there are obvious potential issues, you might be marked down. For example, I can document that the system assume no concurrent update, but then, this might not be a good decision.

Nick

[Dieskun Koper]

Hello Eric,

I also read the file just once and cache the data, and update the file when necessary. Like David's, my instructions said there was 1 server. I explained the design in my choices.txt, not in my userguide.txt (I felt it is of no concern to the user).

I feel searching is a frequently used operation, much more often than update. As DB access is usually a bottleneck in 2 and 3 tier applications, I never really considered not caching this data.
But that's more based on my experience in my work than anything related to what is written in my instructions. If you feel more confident about not caching this data, by all means do not cache it. Worst is to make a choice you cannot really defend.

Regards,
Dies

[Nicholas Cheung]

As said, no matter what implementation you are using, you must be careful about whether the data, no matter in cache or file system, is consistent. As you might read from other threads that, most of us, if not all, scored only 44 out of 80 on locking. This might be because there are some cases that, we logically think it works or it should be capable to handle, but then, our beloved assessors found problems!

In case you need to use cache, do make sure that your design does not violate the serializability theory, and the data is always being consistent.

Nick
[ December 28, 2004: Message edited by: Nicholas Cheung ]

[Beny Na]

hi Nick...

i am thinking of using observer pattern to notify all clients if there was any changes in the databse(.db file) by any clients.
The problem is the server has to read for (t) time to see if the file has been changed. can it affect the performance? IMO it won't effect so much, what do you think Nick?


thks

[Nicholas Cheung]

You dont need to worry about performance issues, because it is basically not considered by the assestors.

However, for making use of observer, you need to cater for some exceptional cases. For example, when client X books record 1, you notify client Y and Z. However, an exception occurs when notifying client Y, so, what will you do? In case, later, client Y makes the same booking as client X, what will you do?

Thus, observer alone is not enough, and you need additional mechanisms to make sure the consistency, and you need to make sure that you have catered for all cases, both normal and exceptional.

Nick

[Eric Chang]

Thanks for all the replies and comments. From what I've read, I gather that it is OK for me to cache the records in the ArrayList, and just be very careful about making sure the file and the ArrayList are updated at the same time to keep them consistent. I also use an RAF for the updates. One thing that I was pondering was what to do to update the JTable for each client if a record was updated, and perhaps some sort of observer is necessary. However, I'm a bit clueless on how I could make the server fire some sort of event to each of the clients to tell them to update their JTables upon updating a record. Perhaps someone could shed some light on the matter.
Also, I wondered about the issue about two clients updating the record at the same time, but I figured that I'd lock a record as soon the client enters the modification screen, thereby not allowing two clients to modify the same record.
As for the SpringUtilities, I suppose I'll just decipher it and write my own version of it, with only the parts that I need. Last thing I want to do is blow this exam because of the stupid GUI.
Thanks again!

[Paula Decker]

Hello,

I am caching the data in a HashMap (although ArrayList sounds better). When I update the file, I then update the HashMap. The problem is that to keep the file in sync with the HashMap, I synchronize ALL of my methods in the low level class used for searching, and updating. So even the read methods are synchronized. The search is conducted by using the cache.

This is slow, but the alternative would be to implement a read/write lock on the cache. I opted out of this due to the complexity of yet another locking level. Also, reading the cache instead of the file should speed things up a bit.

Does this sounds acceptable? What do you think?

Thanks.

-Paula

[Beny Na]

You dont need to worry about performance issues, because it is basically not considered by the assestors.
b: thanks...

However, for making use of observer, you need to cater for some exceptional cases. For example, when client X books record 1, you notify client Y and Z. However, an exception occurs when notifying client Y, so, what will you do? In case, later, client Y makes the same booking as client X, what will you do?


b: from your example, what kind of exception could occur when telling client Y rather than network down to server. please give me more examples?
how if i implement in sequence such(to avoid the same booking,client X,Y)
-->lock,make changes,notify all,unlock.


thks