Hmmm, dug around in this some more and it turns out that (the non-optimistic) Hibernate TreeCache glue *is* still literally using putFailFast, even in latest CVS. Looking at the details of the behavior bundle, I'm not sure it could be switched over without some adiditional work. Isolated from parent transaction: putFailFast: Doesn't provide, Hibernate suspends its transaction itself before calling into the TreeCache. (There's a bug here, the suspended transaction leaks onto the invocation context used for putFailFast, so putFailFast creates its locks owned by the suspended transaction!) FAIL_SILENTLY: Provides automatically Replicates asynchronously even if the cache is REPL_SYNC putFailFast: Provides (hacked into the ReplicationInterceptor) FAIL_SILENTLY: Doesn't provide. Maybe could be a separate option? Lock failure immediate without waiting for a lock timeout: putFailFast: Provides FAIL_SILENTLY: Doesn't provide (??? Am I missing something?) Lock failure ignored: putFailFast: Doesn't provide; for local failure, caller can catch TimeoutException. failure on (async) replication is logged at level ERROR. FAIL_SILENTLY: Provides, sort of. Except for the one particular case of JBCACHE-767 (now) silent isn't very silent... it logs at level INFO. For the short term I'm going to see if I can come up with fixes for the two putFailFast bugs noted above (leak of locks onto suspended transaction, ERROR logging on replication). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974070#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...