• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

File Record Number

 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
When I call the update, delete and read methods I think I need to be referring to the file record number (the position of the record in the database file) rather than the record number in the cache. This is because the cache could have been updated since the last time the GUI queried it.
1. Does everybody else do this?
2. How do you store the active records in the record cache and still have an index to the position of the record in the file?
3. If I use the record cache record number (e.g. the index in the List) then do I just need to make sure that I check the record is the same one as the user has attempted the operation on and if not then throw an exception?
This seems like a possibility and I know that this won't be an issue in the assignment because it only performs updates, reads and searches but I guess that we need to think of all possible uses of the server (including applications that perform many deletes and creates as well as other operations).
Any thoughts?
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jon,
When I call the update, delete and read methods I think I need to be referring to the file record number (the position of the record in the database file) rather than the record number in the cache. This is because the cache could have been updated since the last time the GUI queried it.

If you implement a cache, the file and the cache contents normally must stay in sync, meaning that you shouldn't have such worry from a business method.
Where you are right is that you should - after lock - check that the record you want to update didn't change since you read it. As we use optimistic locking (locking just before an update) that's the way to avoid lost updates:

Regards,
Phil.
 
Jon Pengelly
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Phil.
I think the worry for me is that because a client will populate it's JTable with the record details from the cache at the last time that it has called the server, it is possible that the cache is changed after this and so the record number details may be out of date.
For example,
1. A client gets the file deatils from the cache and populates it's JTable.
2. A record is deleted by another client and so is removed from the cache.
3. All records after the deleted record would have there an incorrect cache index (+1) from the client that was populated before the record was deleted.

Do you see my worry? I actually think it is not too bad because I will just check that the record hasn't been changed but like I said in my first post - If an application performed many deletes/inserts then it may throw lots of "record has been altered by another client" exceptions, which would frustrate the users.
Any comments?
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jon,
Do you see my worry?

Now I see it. But records should be accessed from the cache or the file with the *same* record numbers. In other words, the fact that records are deleted should have no influence on the way remaining records in the cache are accessed.
If the cache container is a HashMap (key=recNo) you've nothing special to do.
From your post, I guess you use an ArrayList indexed by recNo. You could then represent deleted records by null items in your ArrayList.
Regards,
Phil.
[ February 19, 2004: Message edited by: Philippe Maquet ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic