If so, how are you ensuring that a record can only be deleted by the client who locked the record?// Locks a record so that it can only be updated or deleted by this client.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
SCJP, Pre-SCJD (URLyBird 1.3.1), Teradata Cert'd Prof
Saheed Adepoju<br />SCJP 1.4<br />SCJD (B&S..In progress)
Carlo Spelgatti<br />Dipl. Informatik Ing. ETH / SCJP / SCJD<br />Ch�ngengass 3<br />8805 Richterswil<br /> <br />P: 044 793 10 50<br />M: 078 698 07 92<br />ICQ: 401810960
Originally posted by Andrew Monkhouse:
Hi Tim,
Do you have the following comment in the instructions for your required lock() method? If so, how are you ensuring that a record can only be deleted by the client who locked the record?
Regards, Andrew
Originally posted by Kevin Conaway:
Tim,
I think you should make every effort to protect the client (when I say 'client', I meant a client of the database) from themselves. So, if a client requests a modification (update/delete), you should check to make sure they have the lock for that record before making the modification.
Kevin
The client should do what you suggest, however the instructions indicate that the Data class itself should enforce that this is happening.Shouldn't this be handled in the db.client code? Meaning, the code is as is right now but when the method is called from of the db.client classes then a call to data.lock() is made first before calling the delete() method.
You have the basic concept for the solution.I don't see though how this can be implemented in the delete method itself other than maintaining a map which contains the lock owners and then checking the map if contains something before making the delete operation.
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 Tim, You have the basic concept for the solution.There are multiple ways you can achieve this - rather than me suggesting one (or having me suggest multiple solutions
) I suggest you think about it, and explore your ideas here.
Regards, Andrew
SCJP, Pre-SCJD (URLyBird 1.3.1), Teradata Cert'd Prof
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
That depends on a number of other issues.in lock(), get the Thread.currentThread().getName(), if it's empty, assign an unique name to it and associate with the record that this thread locked. Would this be an acceptable approach?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
SCJP, Pre-SCJD (URLyBird 1.3.1), Teradata Cert'd Prof
Bob N
CSSLP
SCJP - 1.4
SCJD - (B&S) Used 1.5 And It Runs On Solaris10
SCWCD - Thanks to HFSJ!!
Originally posted by Andrew Monkhouse:
Hi Tim,
I think I am missing some part of your overall design. How are you associating recordLock with the client?
Regards, Andrew
Tim and Saheed, it looks like you are both tying up all the synchronized code in your entire Data objects. This may not be bad with 33 records, but from a design standpoint I totally disagree.
Saheed Adepoju<br />SCJP 1.4<br />SCJD (B&S..In progress)
Originally posted by Tim Fernandez:
Hi Andrew,
I just created this recordLock (ReentrantLock) and it is not all associated to the client. It's just that i thought enclosing the the code i have above with this recordLock will ensure that the one who locked can only be the one to update it and unlock it. In the SCJD book though, this is not at all done (ensuring that only a client who locks the update code can update the code) or is it?
Bob N
CSSLP
SCJP - 1.4
SCJD - (B&S) Used 1.5 And It Runs On Solaris10
SCWCD - Thanks to HFSJ!!
Saheed Adepoju<br />SCJP 1.4<br />SCJD (B&S..In progress)
Bob N
CSSLP
SCJP - 1.4
SCJD - (B&S) Used 1.5 And It Runs On Solaris10
SCWCD - Thanks to HFSJ!!
I have gone to look for myself. If I should return before I get back, keep me here with this tiny ad:
Clean our rivers and oceans from home
https://www.kickstarter.com/projects/paulwheaton/willow-feeders
|