Setting Option ineffective if CacheLoader or BuddyReplication is used
---------------------------------------------------------------------
Key: JBCACHE-1139
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1139
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.1.SP3
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Critical
Fix For: 1.4.1.SP4
Both CacheLoaderInterceptor and DataGravitationInterceptor have "lock" methods
that create a MethodCall and pass it to the head of the interceptor chain. Problem is,
when the TxInterceptor handles that "lock" call, it will scrub any Option from
the thread on the way out. Once this happens, the option is effectively lost from the
main call.
A major effect of this is BuddyReplication with autoDataGravitationEnabled=false does not
work if a CacheLoader is configured. You can't effectively set a
setForceDataGravitation(true) option, as the CacheLoaderInterceptor.lock call will scrub
the option. This breaks buddy replication for EJB3 SFSBs, which is the reason I marked
this Critical.
I'm about to check in a change to BuddyReplicationWithCacheLoaderTest that will
demonstrate the issue.
Buddy replication for EJB3 SFSBs works fine in AS trunk w/ JBC 2.0.0.CR3, so I'm
assuming this issue doesn't exist in 2.0. I'll port the unit test to JBC HEAD
though.
I have a simple solution whereby in the lock() methods, any existing Option is cached
before the method call is dispatched, and then rebound to the thread in a finally block.
This allows the unit test to pass, and EJB3 BR works. I'll check it in once the JBC
testsuite runs and shows no regressions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira