SCJP 1.4<br />SCJD <br />SCWCD (Studying)
SCJP 1.4<br />SCJD <br />SCWCD (Studying)
Originally posted by Lara McCarver:
e key from the record.
So really, you are just adding an Adaptor on top of your current Data class... it shoudn't be too bad.
SCJP 1.4<br />SCJD <br />SCWCD (Studying)
SCJP 1.4<br />SCJD <br />SCWCD (Studying)
That's one solution. The alternative solution is to let the caller worry about it. That is, leave the Data class along with no knowledge of how it should handle the co-modification, but load the caller with the responsibility to check if the record was deleted/replaced in the middle of the modification request.
Originally posted by Jack Gold:
Secondly, this is not as simple as the client doing a lone call to checkModifyDeleted(PK) before booking(modifying) a record. Technically, for this to be failsafe, it needs to be atomic.
Client A could do the check and find out the record has not changed, then ClientB could change the record before ClientA has a chance to finish his booking (or deletion) operation.
Dinner will be steamed monkey heads with a side of tiny ads.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|