[infinispan-dev] Infinispan URL format

Sanne Grinovero sanne at infinispan.org
Wed Jun 1 05:29:25 EDT 2016

The implementation proposals seem slick, but I'd have some doubts
about allowing overrides to the datastore settings at this level.

The hot-rod proposal looks fine, as similarly to a RDBMs it helps to
figure how to connect to a specific database by expressing:
 - how to reach the DB
 - WHICH database you mean to connect to

In case of the proposals for Infinispan Embedded, I think we fail
these goals: you need to provide a means for multiple applications to
"connect" to the same database. So the container needs to be able to
distinguish *same* Cache instance from a different one, and this might
get complex if the URL includes a mixture of client specific settings
(i.e. how to connect) and configuration of the Cache (i.e. TTL and
CacheStore options).
It also gets messy in terms of lifecycle: do you stop the CacheManager
when the last client is undeployed?

I'd rather see an approach based on naming lookup. How the Cache is
configured, started and "bound" to that specific name should be
treated separately.

For that purpose, I think the WildFly caches configuration can be
considered the first step, and the next would be to allow a "Cache
configuration fragment" to be deployed either included with an
application, or independently from an application.


On 1 June 2016 at 08:24, Tristan Tarrant <ttarrant at redhat.com> wrote:
> So you've been putting that XSL/Xpath knowledge to good use I see. I
> like it.
> Tristan
> On 01/06/2016 09:02, Radim Vansa wrote:
>> On 05/31/2016 01:33 PM, Galder Zamarreño wrote:
>>> Comments inline:
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>> On 30 May 2016, at 09:46, Tristan Tarrant <ttarrant at redhat.com> wrote:
>>>> In the past there has been talk of representing a connection to
>>>> Infinispan using a URL, in particular for HotRod.
>>>> The Hibernate OGM team is now working on adding NoSQL datasources to
>>>> WildFly, and they've asked for they should represent connections to
>>>> various of these.
>>> ^ What's this trying to solve exactly?
>>>> For Hot Rod:
>>>> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>>>> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
>>>> currently support this, so this is forward-looking).
>>>> Obviously we will support all of the HotRod properties for specifying
>>>> things like security, etc.
>>> ^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?
>>>> For Embedded:
>>>> infinispan:embedded:file://path/to/config.xml (for specifying an
>>>> external config file)
>>>> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
>>>> in JNDI)
>>>> infinispan:embedded: (configuration specified as properties)
>>>> For the latter, we also need to be able to represent an infinispan
>>>> configuration using properties with a simple mapping to XML
>>>> elements/attributes, e.g.
>>>> cache-manager.local-cache.mycache.eviction.size=1000
>>> ^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?
>> The first idea would be to make the left-hand side XPath expressions, so
>> it would be
>> cache-container[@name=myManager].local-cache[@name=myCache].eviction.size=1000
>> As we probably want to select only on the name attribute, this could be
>> sufficient and less verbose:
>> cache-container[myManager].local-cache[myCache].eviction.size=1000
>> I wouldn't mix 'schema' of the property with user-defined identifiers -
>> those brackets clearly separate them for good.
>> There are cases where you have multiple children in one element - custom
>> interceptors, groups, persistence (though the current schema tells me I
>> can have only one store defined)... and there is no clear identifier (as
>> cache name, or backup site). I would suggest that there a custom
>> identifier that is not present in configuration would help user identify
>> this, e.g.
>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].class=org.my.FooStore
>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].file=/some/path
>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].class=org.my.BarStore
>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].url=http://example.com
>> My 2c
>> Radim
>>> Cheers,
>>>> Comments are welcome
>>>> Tristan
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

More information about the infinispan-dev mailing list