[JBoss JIRA] Reopened: (JBCACHE-347) Replay tx if tx is created implicitly and fails on commit
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-347?page=all ]
Manik Surtani reopened JBCACHE-347:
-----------------------------------
Assignee: (was: Manik Surtani)
> Replay tx if tx is created implicitly and fails on commit
> ---------------------------------------------------------
>
> Key: JBCACHE-347
> URL: http://jira.jboss.com/jira/browse/JBCACHE-347
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.4
> Reporter: Manik Surtani
> Fix For: 2.0.0.GA
>
>
> With optimistic locking, we first check for an existing transaction, and if there isn't one, we implicitly start one. Before the method returns, if we started the tx ourselves, we make sure we commit it.
> There is scope to 'replay' the tx a fixed number of times here if the commit fails.
> At the moment, if the developer explicitly starts a tx before any cache operations, the cache may throw a RollbackException if it is unable to commit. If the developer doesn't explicitly start a tx, the cache may fail silently if it is unable to commit, logging errors but not throwing any exceptions. So there is scope here for silent retries without changing usage semantics.
--
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
18 years, 4 months
[JBoss JIRA] Reopened: (JBCACHE-163) Consolidate jboss related libraries
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ]
Manik Surtani reopened JBCACHE-163:
-----------------------------------
Assignee: (was: Manik Surtani)
> Consolidate jboss related libraries
> -----------------------------------
>
> Key: JBCACHE-163
> URL: http://jira.jboss.com/jira/browse/JBCACHE-163
> Project: JBoss Cache
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Ben Wang
> Priority: Minor
> Fix For: 2.0.0.GA
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Currently the jboss dependent packaging in JBossCache is a bit scattered. We use the packaging from jboss-head but they are different the packaing, say, jboss-4.0.
> For example, jboss head recently split jboss-j2ee.jar into jboss-j2ee and jboss-j2se.jar of which has no interests to us at all.
> Nonetheless, our dependency on jboss is very minimal now. So maybe we should think of consolidating all the jboss packaging into a single one? In theory, we should use the jboss packages from full release, like AS4.0.2.
--
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
18 years, 4 months
[JBoss JIRA] Reopened: (JBCACHE-250) Hierarchical caches not working when using JBoss service
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-250?page=all ]
Manik Surtani reopened JBCACHE-250:
-----------------------------------
Assignee: (was: Manik Surtani)
> Hierarchical caches not working when using JBoss service
> --------------------------------------------------------
>
> Key: JBCACHE-250
> URL: http://jira.jboss.com/jira/browse/JBCACHE-250
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.3
> Reporter: Nimrod Rivier
> Priority: Minor
> Fix For: 2.0.0.GA
>
>
>
> I tried to configure a hierarchical cache, composed of a first-level memory-only cache,
> and a second-level file-only cache. It seems not to work when I the caches are jboss services,
> but works when I use plain classes.
> Details:
> The caches are created as follows:
> TreeCacheMBean sCacheSecondLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName1, server);
> TreeCacheMBean sCacheFirstLevel = (TreeCacheMBean)MBeanProxyExt.create(TreeCacheMBean.class, serviceName2, server);
> LocalDelegatingCacheLoader sCacheLoader = new LocalDelegatingCacheLoader(sCacheSecondLevel.getInstance());
> sCacheFirstLevel.setCacheLoader(sCacheLoader);
> I then insert elements into sCacheFirstLevel, and it seems they are not delegated into sCacheSecondLevel .
> Adding the following did not help
> sCacheFirstLevel.stopService();
> sCacheFirstLevel.startService();
> sCacheSecondLevel.stopService();
> sCacheSecondLevel.startService();
> When I use the following code to create the caches, everything seems to work fine:
> sCacheSecondLevel = new TreeCache();
> sCacheSecondLevel.setCacheLoaderClass"org.jboss.cache.loader.FileCacheLoader");
> Properties filecacheLoaderProperties = new Properties();
> filecacheLoaderProperties.put("location","c:\\temp\\cache\\requests");
> sCacheSecondLevel.setCacheLoaderConfig(filecacheLoaderProperties);
> sCacheFirstLevel = new TreeCache();
> CacheLoader cacheLoader = new LocalDelegatingCacheLoader (sCacheSecondLevel);
> sCacheFirstLevel.setCacheLoader(cacheLoader);
> /* Configure the caches (removed) */
> sCacheSecondLevel.createService();
> sCacheSecondLevel.startService();
> sCacheFirstLevel.createService();
> sCacheFirstLevel.startService();
>
>
--
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
18 years, 4 months
[JBoss JIRA] Reopened: (JBCACHE-131) Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-131?page=all ]
Manik Surtani reopened JBCACHE-131:
-----------------------------------
Assignee: (was: Manik Surtani)
> Cache Loaders (when unshared, and not used with eviction) Should Persist Transient State Upon Startup
> -----------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-131
> URL: http://jira.jboss.com/jira/browse/JBCACHE-131
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.2
> Reporter: Jimmy Wilson
> Priority: Minor
> Fix For: 2.0.0.GA
>
> Attachments: TreeCache.zip
>
>
> Given the following single, unshared cache loader use case in the TreeCache documentation:
> "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store"
> A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability.
> I have modified TreeCache to handle this situation, and I will attach the modified code to this issue.
--
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
18 years, 4 months