For example, it seems to me that, operationally, you might run into trouble if thread A has a lock on record x for the purposes of performing a delete. Thread A finishes the delete, releases the record x lock, whereupon thread B siezes the lock to perform an update on record x. Is it a problem since record x is now a deleted record? At the time thread B initiated the update, it was a legitimate operation. While waiting, it became illegitimate.
B.S. University of Wisconsin<br />SCJP 1.4 (85%)<br />SCJD 1.4 (92%) B&S Contractors
Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Originally posted by Bridget Kennedy:
I'm having a little trouble with the spec in the area of record locking and thread management. I infer from the spec that clients queue up for access to specific records. I'm not sure what level of complexity is expected for managing the queue. For example, it seems to me that, operationally, you might run into trouble if thread A has a lock on record x for the purposes of performing a delete. Thread A finishes the delete, releases the record x lock, whereupon thread B siezes the lock to perform an update on record x. Is it a problem since record x is now a deleted record? At the time thread B initiated the update, it was a legitimate operation. While waiting, it became illegitimate. Is it illegitimate? Is it ok to usurp prior actions?
I tend to fall back on the notion that I probably won't get dinged for providing too much complexity. But I don't want to spend time unnecessarily on sophisticated solutions.
Thoughts and/or links to prior discussions of this issue will be most appreciated.
Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Suppose you have a scenario where the queued operations are both record updates. Say client A is booking record x. Client B is locked out, but gets the lock upon completion of client A's action. What should happen next? Client B books record x, effectively cancelling client A's action? This just doesn't seem right to me - especially considering, at the time the competing request is queued, client B is not aware of client A's booking.
B.S. University of Wisconsin<br />SCJP 1.4 (85%)<br />SCJD 1.4 (92%) B&S Contractors
Originally posted by Koen Serneels:
The first level is the one where no actions occur at the same time. This means that user one does a read, 5 minutes later user b does a read, one minute later he does an update and again 5 minutes later user a updates his version. So no queue or waiting was necesairy for this example.
Originally posted by Koen Serneels:
The second level is the one where multiple request are handled at the 'same' time. Meaning that both user one and two are doing the update (but with different data) at the same moment. The first level will fail to notice this (in very rare occasions, but it can happen) since the thread of user two can pass the up to date check before user one has written his update, then user two will be added to the queue and wait until user one finishes and then afterwards do his update.
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
Originally posted by Andrew Monkhouse:
Hi Koen,
I suspect you may be overcomplicating this. Consider the following bit of psuedocode:
SCJP 1.4<br />SCJD 1.4
Hey Andrew, if I am correct, verifying the record integrity would be checking the "owner" field in B&S to check whether there is a an 8 digit customer ID or not. Is this correct?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
What part of the code were you referring to for this?
I would rather have the extra few bytes transferred at the time of booking (and there will be far fewer bookings than reads anyway, so you are not saving that much overall) and have the ability for the Data class to be enhanced at a later date.
SCJP 1.4<br />SCJD 1.4
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Originally posted by Andrew Monkhouse:
Hi Daniel,
I assumed (possibly incorrectly) that since the update method allows for you to pass empty fields, then you might be passing empty fields to your booking method. If this is the case, then your verification cannot validate those empty fields.
Regards, Andrew
SCJP 1.4<br />SCJD 1.4
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog