Hide Forgot
Hello, I went through it and would like to suggest some minor cosmetic changes, if possible. B.2. 1. -- this is a strange sentence "1. If Key K is hashed to nodes {A,B} and transaction TX1 acquires a lock for K on, for example, node A." --- then? what? I think I miss something here, maybe not. Or 1. should be predecessor for point 2.? What is a source of these information about consistency guarantee? Any web page, ISPN internal DOC? Thank you! B.4. About JSON -- not mentioned ever before in the documentation -- remove B.4 completely B.5. About RELAY2 This sentence -- The RELAY protocol bridges two remote clusters -- needs some introduction: "there is/exists also REALY protocol... which..." because this looks like a mistake. The first sentence is talking about RELAY2 and immediately after it is something about RELAY. Reader may be confused. B.10.2. "The following is an example of the incorrect method to deal with this" For me: "to deal with this" -- looks like a proposed solution, but it's not, this is the incorrect example. It may be little bit confusing. Can it be introduced like: "This it the example of incorrect usage...." or smth like that? :) ------ + do we know the source of these information? I'm curious about source of consistency and c. guarantee and externalizers samples. (Need to look at it thoroughly and understand it a little bit better) Thank you!
(In reply to Tomas Sykora from comment #0) > ------ > > + do we know the source of these information? I'm curious about source of > consistency and c. guarantee and externalizers samples. (Need to look at it > thoroughly and understand it a little bit better) Hi Tomas, This chapter is something I'm sure we've had since the beginning may have originally just been a Reference chapter of sorts. Any changes you suggest we would be happy to accommodate. I am assigning this bug to Bobb.
Suggesting some changes for B.2.: Despite the locking of a single owner instead of all owners, Red Hat JBoss Data Grid's consistency guarantee remains intact. Let's (TODO: let's needs proper DOC wording) consider the following situation: 1) If Key K is hashed to nodes {A,B} and transaction TX1 acquires a lock for K on, for example, node A and 2) If another cache access occurs on node B, or any other node, and TX2 attempts to lock K as a result, this access attempt fails with a timeout because the transaction TX1 already holds a lock on K. This lock acquisition attempt always fails because the lock for key K is always deterministically acquired on the same node of the cluster, irrespective of the transaction's origin.
Cool! Thanks for changes. Absolutely last think I noticed: B.2. About Consistency Guarantee, point 2: If another cache access occurs on node B, or any other node, and TX2 attempts to lock K, this access attempt fails with a timeout because the transaction TX2 already holds a lock on K. The second TX2 has to be TX1. The completely correct point 2: If another cache access occurs on node B, or any other node, and TX2 attempts to lock K, this access attempt fails with a timeout because the transaction TX1 already holds a lock on K. I will verify it once it is fixed. (Short question here -- do we (QE) have write/modification access to docs? For case of small correction, so we don't need to bother you? Thanks!)
The fix for this bug is now generally released and available here: https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.2/index.html