But how can we make sure user will first call lock and then delete .
I saw some posting for test cases ,there first call to lock then delete , update .
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Roberto Perillo wrote:
You can make sure by verifying in your delete method if the user trying to delete the record is the same one that previously locked it. In my case, if the record was not locked, then I throw an IllegalStateException.
// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
Marc Marechal
MCSE, CCNP, SCJP 5.0, SCBCD 5.0 (Beta), SCJD 6.0
SCJP, SCJD
Roel De Nijs wrote:... if i want to update record 1, i have to do it like this.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse wrote:
I hope there is a verify record status between steps 2 & 3.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse wrote:No, I mean business logic that checks that the record can still be booked (or possibly deleted).
Andrew Monkhouse wrote:
# lock record
# check if it has been booked
# if not, then book record
# otherwise display "sorry" message to user
# always unlock
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
- 1.lock the record
2. read the record and verify it's still available
-3. if it is, update the according record
-4. and finally delete this record
Roel De Nijs wrote:
your last remark is correct and i would even say it's not needed to throw RNFE from update, delete and unlock (because it should not occur at all, if it occurs your lock-method's implementation or your synchronization/concurrency is wrong)
SCJP 1.4 100%
SCJD 99.5%
SCJP 1.4 100%
SCJD 99.5%
SCJP 1.4 100%
SCJD 99.5%
If you try to please everybody, your progress is limited by the noisiest fool. And this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|