January 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1468) JBoss Cache ignores transactions with STATUS_MARKED_ROLLBACK and auto commits data changes

by Eduardo Martins (JIRA)

JBoss Cache ignores transactions with STATUS_MARKED_ROLLBACK and auto commits data changes ------------------------------------------------------------------------------------------ Key: JBCACHE-1468 URL: https://jira.jboss.org/jira/browse/JBCACHE-1468 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.0.2.GA Reporter: Eduardo Martins Assignee: Manik Surtani See jboss forum reference for complete issue description and jboss cache logs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1469) DummyBaseTransactionManager behaves incorrectly with Status.STATUS_MARKED_ROLLBACK

by Manik Surtani (JIRA)

DummyBaseTransactionManager behaves incorrectly with Status.STATUS_MARKED_ROLLBACK ---------------------------------------------------------------------------------- Key: JBCACHE-1469 URL: https://jira.jboss.org/jira/browse/JBCACHE-1469 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.0.2.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.3.GA When an ongoing transaction has been marked as STATUS_MARKED_ROLLBACK, calling commit() simply throws a RollbackException() and does not actually attempt a rollback (which would involve notifying Synchronizations, etc). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1471) Slow cache.get for fqn with a large number of key/value entries.

by Alex Kluge (JIRA)

Slow cache.get for fqn with a large number of key/value entries. ---------------------------------------------------------------- Key: JBCACHE-1471 URL: https://jira.jboss.org/jira/browse/JBCACHE-1471 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 3.0.2.GA Environment: Encountered when using a TcpDelegatingCacheLoader Reporter: Alex Kluge Assignee: Manik Surtani Priority: Minor Stress tests of JBoss Cache with a far cache, and a large number (10K+) of key/value pairs in a node did not perform as well as I would expect. On a read of the cache, cache.get(fqn, key), a large amount of time was spent determining whether the data needed to be loaded from the far cache. The big time sink is the n. getKeysDirect() call in org.jboss.cache.interceptors.CacheLoaderInterceptor, which copies the keyset. As expected, introducing a containsKeyDirect(K key) method to NodeSPI, and implementation classes where needed, allowed for a significant speedup when the new method is used in place of n.getKeysDirect().contains(key). If this is a reasonable path, I have attached the patch file to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1438) Apply state transfer changes using CacheLoader.put(List<Modification>), not one by one

by Elias Ross (JIRA)

Apply state transfer changes using CacheLoader.put(List<Modification>), not one by one -------------------------------------------------------------------------------------- Key: JBCACHE-1438 URL: https://jira.jboss.org/jira/browse/JBCACHE-1438 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 3.0.0.CR3 Reporter: Elias Ross Assignee: Manik Surtani Some cache loaders benefit from this change. JDBM is greatly sped up. Should revisit how transactions are batched for JDBC and other cache loaders as well during state transfer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1413) Investigate the use of SQL insert-or-update semantics for more efficient JDBCCacheLoader internals

by Manik Surtani (JIRA)

Investigate the use of SQL insert-or-update semantics for more efficient JDBCCacheLoader internals -------------------------------------------------------------------------------------------------- Key: JBCACHE-1413 URL: https://jira.jboss.org/jira/browse/JBCACHE-1413 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Cache loaders Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA, 2.X Related to JBCACHE-1410 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1407) Region-based marshalling to support multiple regions in a PREPARE.

by Brian Stansberry (JIRA)

Region-based marshalling to support multiple regions in a PREPARE. ------------------------------------------------------------------ Key: JBCACHE-1407 URL: https://jira.jboss.org/jira/browse/JBCACHE-1407 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Replication Reporter: Brian Stansberry Assignee: Manik Surtani A transaction can operate on multiple regions within a cache, so the resulting PREPARE will include data from multiple regions. But the region-based marshalling logic will identify a single region Fqn for the message (first one it finds); result is data from other regions will not unmarshall properly. Region-based marshalling needs to be able to handle such a case; analyze the prepare and create a separate region-fqn/data pair for each time the region changes. Storing the node's data in an org.jboss.cache.marshall.MarshalledValue doesn't solve the problem, as in use cases like Hibernate, custom types can be part of the Fqn (below the region root.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1440) Better perfoming cache loader for JDBM

by Elias Ross (JIRA)

Better perfoming cache loader for JDBM -------------------------------------- Key: JBCACHE-1440 URL: https://jira.jboss.org/jira/browse/JBCACHE-1440 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani Patch to add JdbmCacheLoader2 This non-backwards compatible version fixes some performance issues with getChildNames(), stores an entire Map not just a key. The store Map not key structure more naturally matches the granularity of cache loader operations. (For post 3.0 release I think.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1442) Improve performance with "Cache.setData" call

by Elias Ross (JIRA)

Improve performance with "Cache.setData" call --------------------------------------------- Key: JBCACHE-1442 URL: https://jira.jboss.org/jira/browse/JBCACHE-1442 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani For a configuration that uses an async cache loader in 3.0, performance of "put(Map m)" may be unexpectedly slow. This is because put(Map) is a merge call and always results in a load. Imagine if put(Map) is being done over the network, e.g. JDBC database. This is not want users would expect. And there's no alternative to this in the current API set. (The work-around is to have cache calls done using a thread pool...) Cache.getNode(X).replaceAll() won't work as it results in a load, and/or a null pointer exception if the node is not found. The old TreeCache from 1.4 had a "put erase" option. I suggest we create a setData() method that does not do a merge. Changes are attached, with some new tests, but I'm not sure the implementation is really complete. The tests set "goals" for the proper behavior of the cache loader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1464) Ability to do bulk gets with TCPCacheLoader

by J B (JIRA)

Ability to do bulk gets with TCPCacheLoader ------------------------------------------- Key: JBCACHE-1464 URL: https://jira.jboss.org/jira/browse/JBCACHE-1464 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Cache loaders Reporter: J B Assignee: Manik Surtani Priority: Minor It would be great if one could make a bulk "get" call through the TcpCacheLoader, currently one has to make many call single calls to get data from the TcpCacheServer. It would be nice to be able to query in bulk for a list of Fqns. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1417) Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size

by Manik Surtani (JIRA)

Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size ---------------------------------------------------------------------------------------- Key: JBCACHE-1417 URL: https://jira.jboss.org/jira/browse/JBCACHE-1417 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA A few ideas here: Users could provide a min and max concurrency level, or a factor of number of nodes in the cache. Need to think of an efficient way to resize the lock collection without affecting ongoing operations. Would also need to consider intelligent collection monitoring to make sure hash functions spread nodes across the locks well, otherwise consider altering the hash function. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues January 2009