8:32 p.m.
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
8:32 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=comments#action_12374821 ]
Brian Stansberry commented on JBCACHE-1175:
-------------------------------------------
Manik, I left this assigned to you in order to get your input, but if you think it's
OK to do, feel free to assign back to me.
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
8:31 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=comments#action_12376926 ]
Manik Surtani commented on JBCACHE-1175:
----------------------------------------
Ok, well if you feel there is relevant enough a use-case, go ahead and add it. I presume
you probably already have a patch for this, even ... :-)
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
8:49 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1175) Option.forceCall(A)sync
[ 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
7:37 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=comments#action_12377179 ]
Manik Surtani commented on JBCACHE-1175:
----------------------------------------
Go ahead with this then if you have the code in place and have the time to write the tests
for it. Let me know if not, attach the patches you have and leave it with me.
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
7:51 p.m.
New subject: [JBoss JIRA] Assigned: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=all ]
Brian Stansberry reassigned JBCACHE-1175:
-----------------------------------------
Assignee: Brian Stansberry (was: Manik Surtani)
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: Brian Stansberry
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
5:29 a.m.
New subject: [JBoss JIRA] Closed: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=all ]
Brian Stansberry closed JBCACHE-1175.
-------------------------------------
Resolution: Done
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: Brian Stansberry
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
5:44 p.m.
New subject: [JBoss JIRA] Reopened: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=all ]
Manik Surtani reopened JBCACHE-1175:
------------------------------------
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: Brian Stansberry
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
5:48 p.m.
New subject: [JBoss JIRA] Resolved: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=all ]
Manik Surtani resolved JBCACHE-1175.
------------------------------------
Resolution: Done
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: Brian Stansberry
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
5:54 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1175) Option.forceCall(A)sync
[ http://jira.jboss.com/jira/browse/JBCACHE-1175?page=all ]
Manik Surtani updated JBCACHE-1175:
-----------------------------------
Fix Version/s: 2.1.0.BETA1
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: Brian Stansberry
Fix For: 2.1.0.GA, 2.1.0.BETA1
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
6189
days inactive
6229
days old
9 comments
2 participants
participants (2)
-
Brian Stansberry (JIRA) -
Manik Surtani (JIRA)