Yes, but as already well discussed and documented, putFailFast is and has
always been a hack job ;)
---
As I said, I have not yet had time to really think through all the various use
cases for SYNCH vs ASYNCH of these putFromExternalRead() calls.
In general, yes, all database writes result in a cache write (there are some
cases that will result in a cache invalidation...). Furthermore, this will
result in the region being write locked by TreeCache for the remainder of the
transaction *on the same node* (TreeCache does *not* provide a distributed lock
manager).
In my mind the general process here would be:
1) get an intention lock (or even re-use write lock here, if it is truly that
'symbolic') when you did the get() if no node/data existed
2) get db state
3) put state into cache, releasing the intention lock
In which case we'd need a way to specify our "do a get and acquire such an
intention lock if no such node/data is found" requirement. Flash-to-bang I do
not feel comfortable with having them be seperate operations, i.e.:
Object state = cache.get(fqn);
if ( state == null ) {
cache.intentionLock(fqn);
state = ...;
}
Instead, maybe something like:
Object state = cache.getWithIntention(fqn);
if ( state == null ) {
state = readFromExternal();
cache.putFromExternalRead(fqn,state); // releases lock
}
...
?
Additionally, I'd throw in that really you and I are simply proposing different
"ignore it" solutions to an exception condition. Perhaps we need to call a
spade a spade and actually throw an exception in this case. There is not a
time I can think of where I do a read from the cache, see no data, read from
the database, go to put that db data into the cache and find data now in the
cache where the overall outcome is anything desireable. Maybe a simple
replication of the cache fill event from another node is ok? But, in general,
simply "not replacing" the data just delays the inevitable. On the other hand,
the "locking" approach makes this consitent at least. The one corner case I
see right now is what do to with a replication event where the node has such an
intention lock.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977625#3977625
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977625
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
