[
http://jira.jboss.com/jira/browse/JBCACHE-1175?page=comments#action_12376935 ]
Brian Stansberry commented on JBCACHE-1175:
-------------------------------------------
I coded it, but it's untested. It gets a bit complex in the OPTIMISTIC case, where if
there's an implicit transaction I have to ensure that the async requirement is stored
in the tx entry so the call gets replicated async when the implicit transaction commits.
Use case is where they're trying to use a single cache for all 2nd level caching.
Cache has to be REPL_SYNC for this to apply, as Hibernate will reject using INVALIDATION
for the timestamps cache. So, currently a fairly narrow use case. But, it's possible
I could eventually get INVALIDATION to work reasonably for timestamps, in which case the
use case would be quite a bit broader.
Option.forceCall(A)sync
-----------------------
Key: JBCACHE-1175
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1175
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.1.0.GA
Add an option to allow an individual call to go async/sync when the cache overall is
configured for the opposite.
This would only be relevant to calls not running in a tx; transactional replication would
use the standard semantic configured for the cache.
Use case for this is Hibernate timestamp region replication, which needs to go async,
while all other Hibernate 2nd level cache traffic goes sync. A good region-based cache
impl would solve the problem as well, but that will surely take quite a while to implement
a while while doing it via an Option looks quite trivial.
--
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