[jboss-user] [JBossCache] - Re: Hibernate/Cache conceptual mismatch
otaylor
do-not-reply at jboss.com
Mon Sep 25 20:29:56 EDT 2006
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#3974070
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974070
More information about the jboss-user
mailing list