August 2007 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-270) Create a notification interceptor

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-270?page=all ] Manik Surtani reopened JBCACHE-270: ----------------------------------- Assignee: (was: Manik Surtani) > Create a notification interceptor > --------------------------------- > > Key: JBCACHE-270 > URL: http://jira.jboss.com/jira/browse/JBCACHE-270 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4beta > Reporter: Hany Mesha > Fix For: 2.0.0.GA > > > The need has arised to create a notification interceptor to handle the callbacks results from different method call events and interceptors emitted events. -- 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-129) Ensure graceful handling of marshalling between different versions

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-129?page=all ] Manik Surtani reopened JBCACHE-129: ----------------------------------- Assignee: (was: Bela Ban) > Ensure graceful handling of marshalling between different versions > ------------------------------------------------------------------ > > Key: JBCACHE-129 > URL: http://jira.jboss.com/jira/browse/JBCACHE-129 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Fix For: 2.0.0.GA > > > backwards compatibility -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-154) Ability to request cache statisics

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-154?page=all ] Manik Surtani reopened JBCACHE-154: ----------------------------------- Assignee: (was: Bela Ban) > Ability to request cache statisics > ---------------------------------- > > Key: JBCACHE-154 > URL: http://jira.jboss.com/jira/browse/JBCACHE-154 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.2 > Reporter: Rich Dredge > Fix For: 2.0.0.GA > > > It would be very helpful to retrieve stats about certain regions of the cache such as: > - Hit/Miss ratio per region > - Access counts > - Number of nodes within a region -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-115) beforeEviction() callback

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-115?page=all ] Manik Surtani reopened JBCACHE-115: ----------------------------------- Assignee: (was: Bela Ban) > beforeEviction() callback > ------------------------- > > Key: JBCACHE-115 > URL: http://jira.jboss.com/jira/browse/JBCACHE-115 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.1 > Reporter: Bela Ban > Fix For: 2.0.0.GA > > -- 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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-139) Node notification event that ecludes myself

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-139?page=all ] Manik Surtani reopened JBCACHE-139: ----------------------------------- Assignee: (was: Bela Ban) > Node notification event that ecludes myself > ------------------------------------------- > > Key: JBCACHE-139 > URL: http://jira.jboss.com/jira/browse/JBCACHE-139 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Fix For: 2.0.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > It will be nice to have a notification mechanism that can exclude myself (who modifies the node in the first place). This is needed in cache invlidation, for example. -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-5) AOP HTTP session replication under Tomcat 5

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-5?page=all ] Manik Surtani reopened JBCACHE-5: --------------------------------- Assignee: (was: Ben Wang) > AOP HTTP session replication under Tomcat 5 > ------------------------------------------- > > Key: JBCACHE-5 > URL: http://jira.jboss.com/jira/browse/JBCACHE-5 > Project: JBoss Cache > Issue Type: Feature Request > Affects Versions: 2.0.0.GA > Reporter: Bela Ban > Fix For: 2.0.0.GA > > Original Estimate: 10 weeks > Remaining Estimate: 10 weeks > > - JBossCache with aop/aopc > - Implemented any required features to support -- 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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2007