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.