I understand Derek's point Phil, but I'm not sure you understand mine: I think this because you're making an interesting, but non relevent, point
.
Please review the question again, because this is integral to the lesson being taught by the SCJD.
What actual, existing, problem are you solving here?
What actual, existing, requirement are you implementing?
If you didn't go to this extra effort, what part of your assignment would you be failing?
Data should protect his cache, period.
This is an interesting assertion. Does a hashmap, even a synchronized one, protect it's cache, period?
What is the principle that leads you to believe that Data should protect it's cache? What existing problem are you solving here? And does that principle cause a conflict when applied to, say, a HashMap?
What actual, existing, problem are you solving here?
What actual, existing, requirement are you implementing?
If you didn't go to this extra effort, what part of your assignment would you be failing?
Felt a bit bad for starting a war
, but, may i join in?
Originally posted by Derek Canaan:
Hi Max and Phil,
Felt a bit bad for starting a war, but, may i join in?
First, i think defensive copying, implemented or not is defendable.
In a cached-design, it's defendable because it makes the data consistent, and the Data class thread-safe. It's the same reason why we implement createRecord() in a thread-safe manner even though we are not explicitly asked to (gui only updates and searches), so that when a client invokes Data.createRecord(), we will not get data inconsistency especially for design that re-uses deleted records.
Furthermore, this gives system consistency. We have a thread-safe readRecord() and a thread-safe createRecord(). Clients are not able to mess up my data when they invoke Data.readRecord() or Data.createRecord(). My assignment states that "marks are awarded for a clear and consistent approach.
Lastly, i want to be protecetd from an assessor who may say, "Hey, i can see a security hole here. The system's locking mechanism is breached." Hence, i choose to err on the safer side.
rgds,
derek
In my assignment, the lockRecord API states:[Max]: That is, you're already requiring that a convention be followed(lock, modify, unlock), so what actual, real problem is being solved here?
It seems to me that the locking API only applies to update and delete. The lock/modify/unlock convention cannot apply to create because you do not have a recordNumber for lock(). So i have to make a decision on readRecord and createRecord. So i decided to make both thread-safe. I realize that in your book (great book by the way), the lock/XXX/unlock convention even applies to reads (getDVD() in DVDDbAdapter class)// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lockRecord(long recNo)
throws RecordNotFoundException;
Originally posted by Philippe Maquet:
Hi max!
quote:
--------------------------------------------------------------------------------
I understand Derek's point Phil, but I'm not sure you understand mine: I think this because you're making an interesting, but non relevent, point .
Please review the question again, because this is integral to the lesson being taught by the SCJD.
What actual, existing, problem are you solving here?
What actual, existing, requirement are you implementing?
If you didn't go to this extra effort, what part of your assignment would you be failing?
--------------------------------------------------------------------------------
What were the questions finally?
When I wrote (as a conclusion of some reasoning):
quote:
--------------------------------------------------------------------------------
Data should protect his cache, period.
--------------------------------------------------------------------------------
you replied:
quote:
--------------------------------------------------------------------------------
This is an interesting assertion. Does a hashmap, even a synchronized one, protect it's cache, period?
--------------------------------------------------------------------------------
As a HashMap has no "cache" (?), please concede that it was hard to understand what you meant exactly.
You next questions were:
quote:
--------------------------------------------------------------------------------
What is the principle that leads you to believe that Data should protect it's cache? What existing problem are you solving here? And does that principle cause a conflict when applied to, say, a HashMap?
--------------------------------------------------------------------------------
Not only both questions are open-ended but they are sort of meta-questions in fact.
To answer such questions you have no other choice but making a first guess on the real topic to be discussed...
quote:
--------------------------------------------------------------------------------
What actual, existing, problem are you solving here?
--------------------------------------------------------------------------------
See above, in the case a cache is implemented, which is not a requirement BTW, but the choice many people make on this forum.
[QB]
Where above? And yes, I know a cache is the choice of many people on this forum. I was one of the first proponents of this approach, long, long ago.
quote:
--------------------------------------------------------------------------------
What actual, existing, requirement are you implementing?
--------------------------------------------------------------------------------
At the highest level, the main requirement in the db area is to implement the interface provided. People who implement a cache make an implementation decision, which corresponds to no requirement (even implicitly). It's OK to do it or not, but if they do it must work correctly. And I think that I demonstrated above that returning from a cache record references instead of a record copy make problem.
[/QB]
quote:
--------------------------------------------------------------------------------
If you didn't go to this extra effort, what part of your assignment would you be failing?
--------------------------------------------------------------------------------
- If you implement a cache which works badly, you could loose a few points if the grader points out the issue.
Originally posted by Derek Canaan:
Hi Max,
quote:
--------------------------------------------------------------------------------
[Max]: That is, you're already requiring that a convention be followed(lock, modify, unlock), so what actual, real problem is being solved here?
--------------------------------------------------------------------------------
In my assignment, the lockRecord API states:
quote:
--------------------------------------------------------------------------------
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lockRecord(long recNo)
throws RecordNotFoundException;
--------------------------------------------------------------------------------
BTW, i do believe you that no points will be penalized even if i didn't do it. It's defendable too.
And IMO, one of the biggest of those is: you're not responsible for how people use the object you provide to them.
Originally posted by Philippe Maquet:
Hi Max,
Agreed, Max. As far as what they can do with the objects you provide them is consistent (and hence can be documented).
Now BTW, do you know *any* database which returns some sort of "pointers" to its internals instead of records copies? Only *one* such database system?
Best,
Phil.
ever heard of EJBs?
Originally posted by Philippe Maquet:
Hi Max,
Max, I must give up here. Not because I would now think that the issue pointed by Derek is not a real issue though.
I think I proved that returning direct references to cache items brings a flaw in the whole DB system (or, anyway, I cannot find better arguments than the ones already produced).
Fair enough, we'll agree to disagree.
I would ask, however, that you not insist to people that is a flaw.
If you choose to disregard this request, please be assured that I will take no offense.
Die Fledermaus does not fear such a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|