October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1172) CacheLoaderInterceptor doesn't load data for Node.getKeys() or Node.getData()

by Brian Stansberry (JIRA)

CacheLoaderInterceptor doesn't load data for Node.getKeys() or Node.getData() ----------------------------------------------------------------------------- Key: JBCACHE-1172 URL: http://jira.jboss.com/jira/browse/JBCACHE-1172 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.1.0.GA CacheLoaderInterceptor.mustLoad always returns false if there is no data key associated with the MethodCall. Effect is calls for CacheImpl._getKeys and _getData don't trigger a load from the cache loader. Added tests testKeyKeys() and testGetData() to CacheLoaderTestsBase to show the issue. Solution is to add a boolean 'allKeys' variable to CacheLoaderInterceptor.invoke. Set it to true if the MethodCall is _getKeys or _getData. Pass the value through to mustLoad, and if true load the data if Node.isDataLoaded returns false. -- 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, 2 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBCACHE-407) Write locks not acquired on newly created empty nodes

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-407?page=all ] Manik Surtani updated JBCACHE-407: ---------------------------------- Fix Version/s: 2.1.0.BETA1 > Write locks not acquired on newly created empty nodes > ----------------------------------------------------- > > Key: JBCACHE-407 > URL: http://jira.jboss.com/jira/browse/JBCACHE-407 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.4.1.GA, 1.4.0.GA, 1.3.0.GA, 2.0.0.GA > Reporter: Brian Stansberry > Assigned To: Manik Surtani > Fix For: 2.1.0.GA, 2.1.0.BETA1 > > > When an empty node is created during a put (e.g node "/a" created as a result of a cache.put("/a/1", "key", "value"); call), only a read lock is acquired on the empty node. If the node is created as part of a transaction, the following failure can occur: > 2 threads, empty cache, READ_COMMITTED > 1) T1 starts a tx > 2) T1 invokes cache.put("/a/1", "key", "value1"); > 3) T2 invokes cache.put("/a/2", "key", "value2"); > 4) T1's transaction rolls back > 5) T2 invokes cache.get("/a/2", "key"); Should get "value2", will get null because the tx rollback will remove node /a and thus /a/2 as well. > This IMO breaks READ_COMMITTED semantics, as T2 is able to "read" /a (in the sense of seeing it exists and thus can have children appended to it) before the tx that created /a is committed. > New unit test IsolationLevelReadCommittedTest.testNodeCreationRollback() demonstrates the 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1142) Update JBoss Cache source code infrastructure

by Manik Surtani (JIRA)

Update JBoss Cache source code infrastructure --------------------------------------------- Key: JBCACHE-1142 URL: http://jira.jboss.com/jira/browse/JBCACHE-1142 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Critical Fix For: 2.1.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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1181) CacheJmxWrappers exposes details as JMX attributes, not operations

by Brian Stansberry (JIRA)

CacheJmxWrappers exposes details as JMX attributes, not operations ------------------------------------------------------------------ Key: JBCACHE-1181 URL: http://jira.jboss.com/jira/browse/JBCACHE-1181 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry getConfigurationAsString(); getConfigurationAsHtmlString(); getCacheDetails(); getCacheDetailsAsHtml(); All are too verbose for exposure as MBean attributes in the JMX console. They need to be converted into operations so users will have to specifically invoke them. A better API would be: printConfigurationAsString(); printConfigurationAsHtmlString(); printCacheDetails(); printCacheDetailsAsHtml(); -- 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, 2 months

2
9
0 / 0

[JBoss JIRA] Created: (JBCACHE-1171) Make constructor Fqn(List<E> names, boolean safe) public

by Brian Stansberry (JIRA)

Make constructor Fqn(List<E> names, boolean safe) public -------------------------------------------------------- Key: JBCACHE-1171 URL: http://jira.jboss.com/jira/browse/JBCACHE-1171 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Minor This constructor saves the cost of making a defensive copy of the passed in List. I've got some code that necessarily creates an ArrayList to pass to the Fqn c'tor, but there's no need to copy it; I hold no ref to the List. Being able to use this c'tor would be a minor optimization. I don't see any reason not to expose it as public; the javadoc for the constructor is clear about the proper usage. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1178) Option to set lock timeout

by Brian Stansberry (JIRA)

Option to set lock timeout -------------------------- Key: JBCACHE-1178 URL: http://jira.jboss.com/jira/browse/JBCACHE-1178 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Allow override of the standard lock timeout on a per-invocation basis. For background on the specific use case that needs this, see http://lists.jboss.org/pipermail/hibernate-dev/2007-September/002669.html -- 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, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1182) JMX wrappers log WARN messages on calling getter for deprecated attributes

by Brian Stansberry (JIRA)

JMX wrappers log WARN messages on calling getter for deprecated attributes -------------------------------------------------------------------------- Key: JBCACHE-1182 URL: http://jira.jboss.com/jira/browse/JBCACHE-1182 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.1.0.GA Logged after viewing a cache mbean in AS's jmx-console: 12:55:33,437 WARN [CacheJmxWrapper] MBean attribute 'CacheLoaderConfiguration' is deprecated; use 'CacheLoaderConfig' 12:55:34,046 WARN [CacheJmxWrapper] MBean attribute 'UseInterceptorMbeans' is d eprecated; use 'ExposeManagementStatistics' These should only be logged for the setter; the setter is what implies conscious usage of the outdated API. -- 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, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1193) Tests should not call Transaction.commit/rollback()

by Jason T. Greene (JIRA)

Tests should not call Transaction.commit/rollback() --------------------------------------------------- Key: JBCACHE-1193 URL: http://jira.jboss.com/jira/browse/JBCACHE-1193 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assigned To: Jason T. Greene Fix For: 2.1.0.GA The JTA spec says that the thread association of a transaction can only be controlled by TransactionManager. The reason is that a Transaction can be bound to multple threads. In order to be compliant, and work with JBoss JTA, we need to ensure that all operations go through TransactionManager -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1175) Option.forceCall(A)sync

by Brian Stansberry (JIRA)

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

18 years, 2 months

2
9
0 / 0

[JBoss JIRA] Created: (JBCACHE-957) Allow per-node configuration of LockParentForChildInsertRemove

by Brian Stansberry (JIRA)

Allow per-node configuration of LockParentForChildInsertRemove -------------------------------------------------------------- Key: JBCACHE-957 URL: http://jira.jboss.com/jira/browse/JBCACHE-957 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 Use the new LockParentForChildInsertRemove as a global default that sets a per-node behavior. Expose an API in Node (not NodeSPI) that allows the application to change the behavior for an individual node. Use case: session replication, which stores data in a structure like this: /SESSION/webapp/session1/.../... /SESSION/webapp/session2/.../... The session managment layer wants the greater correctness that comes with enforcing LockParentForChildInsertRemove="true" with the sessionX node and below. But requiring a WL on /SESSION/webapp before any session could be added or removed will greatly disrupt session creation and expiration. This feature allows the best of both worlds, by allowing the application to set LockParentForChildInsertRemove="false" on /SESSION and /SESSION/webapp. This is a simple alternative to lock striping in the node's children map. -- 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, 2 months

4
8
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007