[JBoss JIRA] Created: (ISPN-317) when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
by Mircea Markus (JIRA)
when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
----------------------------------------------------------------------------------------------------------------
Key: ISPN-317
URL: https://jira.jboss.org/jira/browse/ISPN-317
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.1.0.CR1
at the moment this is split in two operations: a remote get followed by an put. Optimize this to only reside in one operation.
--
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
12 years, 1 month
[JBoss JIRA] Created: (ISPN-201) make JDBC cache store use DB transactions for commit/rollback
by Mircea Markus (JIRA)
make JDBC cache store use DB transactions for commit/rollback
-------------------------------------------------------------
Key: ISPN-201
URL: https://jira.jboss.org/jira/browse/ISPN-201
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.0.0.GA
current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach).
--
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
12 years, 1 month
[JBoss JIRA] Created: (ISPN-78) Large object support
by Manik Surtani (JIRA)
Large object support
--------------------
Key: ISPN-78
URL: https://jira.jboss.org/jira/browse/ISPN-78
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.0.0.GA
if each VM is allocated a 2GB heap and you have a 100 nodes in a grid with 1 redundant copy for each key, you have a theoretical addressable heap of 100GB. But you are limited by (half) the heap of a single VM per entry, since entries are stored whole.
E.g., cache.put(k, my2GBObject) will fail since you need at least 2GB for the object + another 2GB for its serialized form.
This gets worse when you try cache.put(k, my10GBObject). This *should* be possible if we have a theoretical 100GB heap.
Potential solutions here are to fragment large objects, and store each fragment under separate keys. Another approach would be to directly stream objects to disk. etc. Needs thought and design, possibly a separate API to prevent 'pollution" of the more simplistic API. (JumboCache?)
Re: fragmenting, issues to overcome:
How many chunks to fragment into? Max size of each key could be configured, but how do we determine the size of an Object? VM instrumentation? Or perhaps the JumboCache only stores byte[]'s?
--
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
12 years, 3 months