SCJP 1.5, SCJD (URLyBird 1.3.2)
I understand that I need to generate a unique value by doing System.nanoTime()
I am not so clear about the lock cookie concept.
what role will it have in stand alone mode....then how do I get the cleintId value for the standalone mode.
SCJP 1.5, SCJD (URLyBird 1.3.2)
SCJP 1.5, SCJD (URLyBird 1.3.2)
I do exactly the same (and of course also in update/delete/unlock methods).In my lock method I am checking if the clientId is null and if that is true I am setting it to the current thread's id for stand alone mode.
SCJP 1.5, SCJD (URLyBird 1.3.2)
To ensure that the thread who is updating/deleting the locked record actually holds the record (which is the whole purpose of this lock/unlock methods).why do I need to check the clientId inside update/ delete methods?
To ensure that the thread who is updating/deleting the locked record actually holds the record (which is the whole purpose of this lock/unlock methods)
SCJP 1.5, SCJD (URLyBird 1.3.2)
Of course I don't have any idea about what you implemented and how you did it. But if you make sure your Data class is thread-safe and a record can only be updated/deleted/unlocked by a thread owning the lock on that record (by calling lock-method) your Data class isBably Das wrote:Is there something more it?
Have you already thought about the scenario "a thread/client locks (or tries to lock) more than 1 record"?
// 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.
SCJP 1.5, SCJD (URLyBird 1.3.2)
I don't think no instructions explicitly mention handling deadlock as a must-requirement. But in my opinion it is inherently a part of this must-requirement Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.: if your server deadlocks, it is not capable of handling multiple concurrent requests. So you should always handle a possible deadlock situation: with code (if possible) or in documentation (javadoc) and choices.txt (to clearly prove you are aware of this scenario and you have thought about it).My instructions don't appear to state this as a 'must' requirement, therefore, I think as long as its documented, it should be fine.
In my opinion you will only be safe if data.lock(1) is called from the same client! Otherwise 2 different clients will have same lockCookie value and might end up in overwriting each other's updates. And with a lockCookie that is the whole problem: how do you determine that data.lock(1) is called from the same client-application? If you could determine that you would be able to handle deadlock situation within your code.I think another approach at handling the same client trying to get a lock on a record it already has a lock on, is to just return the previously generated cookie value. Since we already know it has locked this record, I think it is safe to return that cookie value again instead of an Exception.
In my opinion you will only be safe if data.lock(1) is called from the same client! Otherwise 2 different clients will have same lockCookie value and might end up in overwriting each other's updates. And with a lockCookie that is the whole problem: how do you determine that data.lock(1) is called from the same client-application? If you could determine that you would be able to handle deadlock situation within your code.
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.
Have you already thought about the scenario "a thread/client locks (or tries to lock) more than 1 record"?
If you were referring to that specific situation, my remark was not needed (and completely useless). But because that was not clear to me (and maybe some other ranchers in the near future) I made my remark.Vlad Djordan wrote:First of all, I was referring to a situation where there is a clear mapping between clients (not cookies) and record numbers
...
I was only trying to explain to Bably that an IllegalStateException can be thrown in this scenario, but it can be handled by another approach.
If you were referring to that specific situation, my remark was not needed (and completely useless). But because that was not clear to me (and maybe some other ranchers in the near future) I made my remark.
There are 29 Knuts in one Sickle, and 17 Sickles make up a Galleon. 42 tiny ads in a knut:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
|