Hi Sergio,
When you put the value on the first node this creates a logical invoke
(wrapped in a TC transaction). This invoke message is sent over the
network up to the L2 where is it applied to the L2s copy of the object
state. The L2 will then look for other nodes that have the map in
their local heap. It then forwards the "invoke" message to these
nodes so that they can add the new mapping to their local copy of the
map. If you inform a second node of the existence of the new mapping
via a separate channel, then this message is racing against the TC
invoke messages. If the read is locked then as part of the read
locking process we wait for the application of all of the changes
performed under the lock to arrive at the L1 before the lock is
awarded. However in your case since there is no read locking when the
second L1 gets the message saying there is a new mapping (via your
second channel) if the "invoke" message from the L2 has not arrived
yet then the L1 has no idea that a mapping for that key exists, and so
it simply returns null.
I assume in your old system you only had incoherent reads for local
mappings turned on. What you will need to do to replicate this effect
is to do something like this:
V incoherentLocalGet(K key) {
V value = map.unlockedGet(key);
if (value != null) {
return value;
} else {
return map.get(key);
}
}
The second get will take a read lock, and will therefore block until
the "invoke" message arrives.
Hope this makes sense to you...
Chris
On Mar 12, 2010, at 8:59 AM, Sergio Bossa wrote:
On Wed, Mar 10, 2010 at 9:27 PM, Chris Dennis
<cden...@terracottatech.com> wrote:
Yes, if the entry is non local (i.e. an ObjectID) then the map will
attempt
to lookup the object from the server, and fault it into the map.
Since that
lookup is done with an ObjectID from a dirty read it is possible
for the
lookup to throw a TCObjectNotFoundException. These will be logged,
but
otherwise ignored and the get will return null.
I've got an odd result with a ConcurrentDistributedMap containing
instances of other ConcurrentDistributedMaps.
I've inserted an item (an inner ConcurrentDistributedMap) into the
first map from node A, then I've tried to retrieve it from node B with
an unlockedGet, but it returned null!
Same test works fine with the old ConcurrentDistributedMap
implementation.
As a side note, if I do a locked get for the first time, subsequent
unlocked get operations works fine.
So, shouldn't the unlocked get always return a non-null value, given
that keys a fully loaded and the object should be automatically
faulted?
And as a related question, when (in my example) does Terracotta load
the inserted key on node B? Does it load the key at insertion or read
time?
--
Sergio Bossa
http://www.linkedin.com/in/sergiob
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
