[jboss-user] [JBossCache] - Re: Hibernate/Cache conceptual mismatch

[steve.ebersole@jboss.com]

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