[infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem

Galder Zamarreño galder at redhat.com
Fri Sep 16 03:49:32 EDT 2011


On Sep 15, 2011, at 5:34 PM, Paul Ferraro wrote:

> </snip>
> 
> The amended Infinispan subsystem schema can be found here:
> https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-infinispan_1_0.xsd

Hmmm, is the xsd meant to show the new changes? I only see custom and file store in there

> 
> For the jdbc cache stores, which come in 3 flavors, I've consolidated
> them into a single configuration element <jdbc-store/>, where the
> variant is implied the defined tables.  After providing default values
> for all the required fields, we arrive at the following minimal
> configuration:
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase"/>
> 
> I started with the assumption that the database resource will always
> come from an AS-managed DataSource.
> 
> To use a string-based jdbc store, we specify the type of table to use:
> e.g.
> 
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
>  <entry-table/>
> </jdbc-store>
> 
> Likewise, if we want to use a binary jdbc store:
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
>  <bucket-table/>
> </jdbc-store>
> 
> Using both <entry-table/> and <bucket-table/> (or neither) indicates the
> use of a mixed jdbc store.
> 
> The tables themselves are fully customizable (shown with their default
> values):
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
> <bucket-table prefix="ispn_bucket" batch-size="100" fetch-size="100">
>  <id-column name="id" type="VARCHAR"/>
>  <data-column name="datum" type="BINARY"/>
>  <timestamp-column name="version" type="BIGINT"/>
> </bucket-table>
> <entry-table prefix="ispn_entry" batch-size="100" fetch-size="100">
>  <id-column name="id" type="VARCHAR"/>
>  <data-column name="datum" type="BINARY"/>
>  <timestamp-column name="version" type="BIGINT"/>
> </entry-table>
> </jdbc-store>

Sounds good. 

> The schema for the remote cache store is far simpler.  You can specify a
> specific remote cache name, server list, and hot rod client properties
> are directly enumerated:
> e.g.
> <remote-store cache="some-named-cache" servers="127.0.0.1:11311">
>  <property name="infinispan.client.hotrod.request_balancing_strategy">...</property>
> </remote-store>
> 
> If the cache attribute is omitted, we assume the default cache is to be
> used.
> 
> Unfortunately, there doesn't seem to be a way to integrate the thread
> pools used by RemoteCache/RemoteCacheManager with the AS7 threading
> subsystem.  In order to do this, RemoteCacheStoreConfig would need
> methods for providing ExecutorFactory implementations, similar to the
> way GlobalConfiguration works.

Hmmm, mind creating a JIRA on this? The HotRod client should be play nicely to allow executor factories to be injected.

> 
> I haven't started on the cloud-based store yet, as it's kind of a
> dependency nightmare.

I know, jclouds' dependency list is huge :(

If Adrian is listening, any chance of somehow reducing it? Otherwise, I think he should be in JUDCon (if not in JavaOne earlier), so I'll try to grab him there :)

> 
> Thoughts?
> 
> Paul
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list