[ https://issues.jboss.org/browse/TEIID-2542?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2542: --------------------------------------- This may be saying a couple of things. 1. Use infinispan for buffering - see TEIID-2169 The short story is that infinispan is neither adaptable enough nor does their file storage strategy offer high enough performance for us to use infinispan for arbitrary buffering (which is generally low reuse high-read/high-write/high-disk use/highly local). 2. Allow internal materialization to use infinispan. That is also touched on by TEIID-2169. This is more doable and the usage pattern fits better (high-read/low-write/replicated) however their is a mismatch between what Teiid is offering and what Infinispan is typically used for. We would either - treat each row as a cache entry and delegate indexing operations to infinispan (which is not a great fit) or make further refinements to our table structure so that the pages could be replicated, but otherwise all logic against them is performed by Teiid. The latter is probably the appropriate approach, but is really just using infinispan as blob storage. Other possibilities include attacking the problem through a modification to the storage layer of h2 or derby - and converting internal materialization logic over to just targeting a "db". That already exists via a generic cache as a map paradigm. Specifically as a replacement for external materialization. Teiid does not have a great story there anyway since we take a hands off approach. In theory you could use "external" materialization with the existing logic by adding appropriate insert/update logic (and a simple way to target a map or list data model) to the infinispan translator. Ideally there would be a way to add secondary search indexes (although I'm not sure how that would work with a simple data model) and if the additional overhead with using the arraytable/objecttable constructs is too mush some additional handling would need pulled into the translator. As an external materialization replacement yes. As an internal materialization replacement, the performance impact is more around minimizing the replication of data (since teiid is using shared nothing instances on each node) and possibly increasing hit ratios - however the amount of memory dedicated to infinispan will vary greatly based upon the implementation paradigm with page/blob storage we have a highly predictable memory footprint. With individual rows memory utilization could vary wildly and without additional tweaking of eviction strategies could lead to default settings that are too conservative and would result in poorer performance. The title of the issue also mentions: This may be referring to 1 above or could also be indicating result set caching. If it's the latter, that is also a possibility to target to infinispan, but here again we have a forced fit. JBoss Cache and earlier infinispans there wasn't a great mechanism to large object storage other than to just store the object in it's batches, which complicates eviction as removing any batch from a result invalidates the whole result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira