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
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
