On Sep 15, 2011, at 5:34 PM, Paul Ferraro wrote:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache