• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: updateRecord & thread-safe design

 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
Would appreciate your comments on this draft design:
updateRecord
------------

Q1: Comments on method, anyone?
Thread-safety design
--------------------
1. Cache is populated when the first Data object is instantiated.
2. The cache object is used as a mutex for read, update, delete, create, lock and unlock (like update method above):

3. The find method has *NO* synchronization on the mutex. It uses the read method which sync on the mutex. I allow dirty reads, and stale records to be presented on gui.
4. The only time where the db file is read is during the first instantiation of Data (in populateCache()). All future reads are done via the cache.
5. The db file is written on during update, delete, create, all of which sync on the mutex. This forces only one method at a time to set the file pointer and do its write operation. Hence i do not need to synch on the raf directly to ensure file position integrity during concurrent read and write.
6. File access (read and write) is done via a local variable raf.
7. All writeToFile is done only after the cache mutex is attained.
Q2. Is design thread-safe?
Q3. Any comments on design?
Q4. Have i got all my bases covered? Any possibility of deadlock, race condition, etc? Any holes?
Q5. One reason why i lean towards Singleton Data is my worry on tester invoking:


Q6. Would design fail this test and causes db.db file to be corrupted if Data is not a Singleton? Singleton Data would force d2 to have same reference/instance as d1.
thanks in advance,
derek
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI Derek,
Q1: Comments on method, anyone?

Your validateCookie() method has a parameter 'c' which is not listed. I assume it is the contractor variable.
You store the cookie itself in the Contractor class don't you? So why not have the validateCookie() method in the Contractor class?
Q2. Is design thread-safe?

It looks like it is. You didn't specify that there is only one instance of the cache, but I am assuming that
Q5. One reason why i lean towards Singleton Data is my worry on tester invoking: [code removed]


I wouldn't get too worried about that - if the tester does try to instantiate their own copy of Data for testing, then they must read the documentation on how to instantiate it, since there are no explicit instructions on instantiators. So as long as you have your documentation correct, then any way you choose to instantiate it will be the correct way.
[Leaving some questions for others to answer]
Regards, Andrew
 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
I'm grateful for your comments.
Your validateCookie() method has a parameter 'c' which is not listed. I assume it is the contractor variable.
Yes, Contractor c = getActiveContractorInCache(recNo);
You didn't specify that there is only one instance of the cache, but I am assuming that
Yes, cache is a member variable in Data.
You store the cookie itself in the Contractor class don't you? So why not have the validateCookie() method in the Contractor class?
Yes, cookie is stored there. Currently, the validateCookie(contractor, cookie) is a private method in Data used in various places in Data. You suggest contractor.validateCookie(cookie). Why is this better apart from aesthetics?
... documentation on how to instantiate it
Do you mean in both choices.txt and javadoc stating that user of Data class should not instantiate more than one Data instance as this may corrupt file? Sorry, i'm not clear. Please advise.
You have been of great help.
Thanks again,
Derek
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Derek,
Originally posted by Derek Canaan:
Yes, cookie is stored there. Currently, the validateCookie(contractor, cookie) is a private method in Data used in various places in Data. You suggest contractor.validateCookie(cookie). Why is this better apart from aesthetics?

It means that you can have the method which validates the cookie inside the class which contains it. At the moment you only need to validate the cookie in your Data class, but in the future you may decide to validate it elsewhere - this would mean that you would have to copy the code elsewhere. It is good practice to keep the methods which act on the object in the object itself.
Originally posted by Derek Canaan:
I'm grateful for your comments. Do you mean in both choices.txt and javadoc stating that user of Data class should not instantiate more than one Data instance as this may corrupt file? Sorry, i'm not clear. Please advise.

Yes, I would document it in both locations.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic