• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S: Booking a changed or replaced record.

 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey all, I'm doing the B&S assignment.

I was wondering what a good solution was to the problem of when booking a record, making sure that it had not been deleted and a new one placed in its stead, or that is had been changed.

I read in a thread somewhere (sorry... I just can't be arsed to sift through and find it, I have read so many threads this past few weeks) that some people were considering not reusing previously deleted records. This would avoid the problem I describe above. I really don't like the idea of this, as it can lead to a very big database file, with very little information in it. Also, it may contravene my spec.

If I was to reuse the record, then would it be acceptable to send a copy of the record (i.e. a Contractor instance) to my book() method? The book method would then lock the record number, check if it aggrees with the Contractor sent, update the record with my client id, and unlock the record? That is:

lock -> check -> update -> unlock

Is there another way around this problem?

Michal
[ August 30, 2004: Message edited by: Michal Charemza ]
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok... I feel a bit lazy about the whole "can't be arsed" thing. If I can't be arsed to do a search then why should people be arsed to help me?

Anyway this is all by the by, as now I've done a few searches and I still can't find the thread I was refering to. Oh well.

Michal
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Reusing a deleted record is better. If you are caching your data, a deleted record is best represented as a null value in an ArrayList. Then you would
a) either find it as a ArrayList.indexOf(null); or get the new record number as ArrayList.size(), and then do ArrayList.set(newRecNo, data);

Basically, reuse is better than expanding the file.
 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Finally, I can come back to work on the project again after a stop for about 3 months. As to this issue, I may not understand you correctly, but here is what I thought:

1. a record has a flag to indicate if it's deleted or not (B&S)
2. it seems doesn't matter whether you cache the db or not, you can always retrieve this "deleted" information from this flag.
3. As I recall my spec, I should reuse the deleted.
4. For a fast searching, have another structure, say, deleted hashtable, initialized at db startup, to store this information, when I come to reuse, find its entry in hashtable then look it in your cache or db file (the hash is just for efficiency and be O(1) comlexity). Finally I will update both hashtable and the flag.
5. As you may know, it will always be in sync since this involves updates in db and hashtable.

Any other comments? Thanks
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Michal,

Your thoughts about handling booking over a record which may have been deleted or replaced is a problem that needs to be addressed in a real life application.

But for the B&S assignment, there is no requirement to allow the user to delete/create/update(except booking) any records. The only things the user can do are search and book. Unless you allow the user to do the other operations, I am not sure if the problem even needs to be addressed.

My 2 cents.
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by T. Anthony Chen:

But for the B&S assignment, there is no requirement to allow the user to delete/create/update(except booking) any records. The only things the user can do are search and book. Unless you allow the user to do the other operations, I am not sure if the problem even needs to be addressed.



I agree that the specifications do not explicitly state that delete/create/update needs to be implemented in the GUI. However, this assignment is supposed to model, albeit simply, a real-world application. The ability to add/delete records to the database seems like a VERY important function: without it this software I think is practically useless... contractors can close down, new ones spring up, they change their size/pricing or even location. I think I may agree with other points about being beyong the scope of this project, especially when it comes to how the program functions internally, but the ability to add/remove records should not not be implemented just because it isn't explicitly asked for. I think that there are probably other things that aren't asked for which I imagine is important. A quick flick through my spec reveals that there is no mention of not letting a deadlock situation occur...

That being said I will still think about it.

Also, if these abilities are not present in the GUI, the interface demands that they are present in the Data class. I think that these methods should be implemented well so it is easy to add on features to the GUI (I think this may be a requirement? or if not I think it is a good principle to program by).

In either case, I do think this problem needs to be addressed.

Michal
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michal Charemza:
Hey all, I'm doing the B&S assignment.

I was wondering what a good solution was to the problem of when booking a record, making sure that it had not been deleted and a new one placed in its stead, or that is had been changed.

I read in a thread somewhere (sorry... I just can't be arsed to sift through and find it, I have read so many threads this past few weeks) that some people were considering not reusing previously deleted records. This would avoid the problem I describe above. I really don't like the idea of this, as it can lead to a very big database file, with very little information in it. Also, it may contravene my spec.

If I was to reuse the record, then would it be acceptable to send a copy of the record (i.e. a Contractor instance) to my book() method? The book method would then lock the record number, check if it aggrees with the Contractor sent, update the record with my client id, and unlock the record? That is:

lock -> check -> update -> unlock

Is there another way around this problem?

Michal

[ August 30, 2004: Message edited by: Michal Charemza ]



This is a problem that needs to be addressed since its very possible that two clients will try to book the same record at the same time. The first client will book it and the second will then overbook it if they don't do the sequence {lock, read, compare to table, update, unlock}. In the rich client model this is not difficult as the client has access to the results of the last search. In the thin client model the book command should take an argument of the record as it was in the search results.

Adding the delete and create commands just makes this worse, but it doesn't change the nature of the problem.
 
T. Anthony Chen
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter your point about booking is valid for a real life application. But I am not sure if it is required for the assignment. Without addressing the problem, the rule of "last change wins" is applied. We don't have a data integraty issue but more of a usability issue. Ideally, a record needs to be locked when a user attempts to modify it, and unlocked after the change has been committed to the db. A different user attempting to modified the same record will be to be informed and stopped.

And Michal, I am interested in what other poeple would think about providing create/delete/update. I am going to open a new post on this topic.
 
reply
    Bookmark Topic Watch Topic
  • New Topic