7:47 a.m.
I know this is much needed, and perhaps 6.0 may be the time to do this. Do we have a list
of things we want to change here?
On the back of https://community.jboss.org/message/726337#726337 it would seem that we
need the ability to pass in the ConsistentHash to the CacheLoader when loading entries, so
that if the cache store is shared, it can selectively load entries targeted to the node in
question. Either that, or to be able to call CacheLoader.load(CacheLoaderFilter) where
CacheLoaderFilter would expose a shouldLoad(Object key).
Other thoughts include better JTA integration, etc?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
8:02 a.m.
I dislike the current way of configuring stores via <property>. As part
of my work for ISPN-1821 I will also introduce the ability for stores to
provide their own configuration parsers so that we can have more
readable schemas.
Participating in JTA is obviously high on the desired list, and I'd also
expose some form of batching so that intelligent cache-store can
colaesce operations together for better performance.
Maybe the ability to introduce some form of compression for values (if
over a certain size threshold).
Tristan
As part of the work I'm doing for ISPN-1821 (being able to parse AS
configurations in Infinispan), I
On 04/02/2012 02:47 PM, Manik Surtani wrote:
I know this is much needed, and perhaps 6.0 may be the time to do
this. Do we have a list of things we want to change here?
On the back of https://community.jboss.org/message/726337#726337 it
would seem that we need the ability to pass in the ConsistentHash to
the CacheLoader when loading entries, so that if the cache store is
shared, it can selectively load entries targeted to the node in
question. Either that, or to be able to call
CacheLoader.load(CacheLoaderFilter) where CacheLoaderFilter would
expose a shouldLoad(Object key).
Other thoughts include better JTA integration, etc?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org <mailto:manik@jboss.org>
twitter.com/maniksurtani <http://twitter.com/maniksurtani>
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:17 a.m.
On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
I dislike the current way of configuring stores via <property>.
As part of my work for ISPN-1821 I will also introduce the ability for stores to provide
their own configuration parsers so that we can have more readable schemas.
That
would be quite nice, as the property-based approach is very error prone. Curious how
you're going to support 'dynamic' xml snippets,through some xml name spaces
perhaps?
Participating in JTA is obviously high on the desired list, and I'd also expose some
form of batching so that intelligent cache-store can colaesce operations together for
better performance.
that's a big one indeed. JTA support won't be available
for all stores, e.g. cloud cache store.
Mind detailing a bit on the batching/colaesce functionality you have in mind?
Maybe the ability to introduce some form of compression for values (if over a certain
size threshold).
I don't think that would require a API change, as this sort of
behaviour seem to be orthogonal and can be handled to a wrapper CacheStore implementation,
very much like the AsyncCache store. Might require a configuration change though. Also I
think this is a good task for an external contributor.
8:31 a.m.
On 04/02/2012 03:17 PM, Mircea Markus wrote:
On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
> I dislike the current way of configuring stores via<property>. As part of my
work for ISPN-1821 I will also introduce the ability for stores to provide their own
configuration parsers so that we can have more readable schemas.
That would be quite nice, as the property-based approach is very error prone. Curious how
you're going to support 'dynamic' xml snippets,through some xml name spaces
perhaps?
Yes, just like the Spring configuration or even the AS7 configuration
itself. In XSD speak they would be complex-types extending a generic
"store" type.
> Participating in JTA is obviously high on the desired list, and
I'd also expose some form of batching so that intelligent cache-store can colaesce
operations together for better performance.
that's a big one indeed. JTA support won't be available for all stores, e.g.
cloud cache store.
I think very few stores would have the ability to participate in
JTA,
but if a cache store can, we should definitely support it.
Mind detailing a bit on the batching/colaesce functionality you have
in mind?
Actually I wasn't thinking about anything more complex than what we
have
already with the applyModifications() call (which in fact could be
reused), but my understanding is that this is only called in
transactional cache operations ? For example the AsyncStore applies
lists modifications internally, without delegating to the cachestore's
implementation.
Tristan
8:45 a.m.
On 2 April 2012 14:31, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 04/02/2012 03:17 PM, Mircea Markus wrote:
> On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
>
>> I dislike the current way of configuring stores via<property>. As part of
my work for ISPN-1821 I will also introduce the ability for stores to provide their own
configuration parsers so that we can have more readable schemas.
> That would be quite nice, as the property-based approach is very error prone. Curious
how you're going to support 'dynamic' xml snippets,through some xml name
spaces perhaps?
Yes, just like the Spring configuration or even the AS7 configuration
itself. In XSD speak they would be complex-types extending a generic
"store" type.
+1, same for the Query options: <properties /> is limiting.
>> Participating in JTA is obviously high on the desired list,
and I'd also expose some form of batching so that intelligent cache-store can colaesce
operations together for better performance.
> that's a big one indeed. JTA support won't be available for all stores, e.g.
cloud cache store.
I think very few stores would have the ability to participate in JTA,
but if a cache store can, we should definitely support it.
Why "definitely" ? It's of course nice to have, but I'm not sure of
the actual value.
If we're planning to include a guarantee of storage in the cacheloader
before the cache operation returns, that means the cacheloader can't
be configured as write-behind, correct?
Now if the CacheLoader is not in write-behind, and it's a different
resource than the Cache itself, I see not much value in it since I
could write in both the cache and the cacheloader from user code
directly, if I needed this functionality.
as I see it, the biggest values of a CacheLoader are:
- to have the cache load from it
- write-behind with coaleshing and batching
which don't sound like it needs to participate in the same transaction
as the Cache operations. It could still use transaction to sync cache
and CacheLoader, but that's possible without changing the interface.
And the current limitations:
- it' s hard to have it "translate" from - taking JDBC for example -
an existing schema. (Or - for example - store the Lucene index in it's
native format on disk)
- doesn't have a "remove expired" function, needs to load all values
to check them
- no way to list all keys without loading the values
- totally no support for MVCC
Imho these are more usefull, unless I'm totally missing what's the
intention of JTA participation ?
> Mind detailing a bit on the batching/colaesce functionality you
have in mind?
Actually I wasn't thinking about anything more complex than what we have
already with the applyModifications() call (which in fact could be
reused), but my understanding is that this is only called in
transactional cache operations ? For example the AsyncStore applies
lists modifications internally, without delegating to the cachestore's
implementation.
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:57 a.m.
On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
On 2 April 2012 14:31, Tristan Tarrant <ttarrant(a)redhat.com>
wrote:
> On 04/02/2012 03:17 PM, Mircea Markus wrote:
>> On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
>>
>>> I dislike the current way of configuring stores via<property>. As part
of my work for ISPN-1821 I will also introduce the ability for stores to provide their own
configuration parsers so that we can have more readable schemas.
>> That would be quite nice, as the property-based approach is very error prone.
Curious how you're going to support 'dynamic' xml snippets,through some xml
name spaces perhaps?
> Yes, just like the Spring configuration or even the AS7 configuration
> itself. In XSD speak they would be complex-types extending a generic
> "store" type.
+1, same for the Query options: <properties /> is limiting.
>>> Participating in JTA is obviously high on the desired list, and I'd also
expose some form of batching so that intelligent cache-store can colaesce operations
together for better performance.
>> that's a big one indeed. JTA support won't be available for all stores,
e.g. cloud cache store.
> I think very few stores would have the ability to participate in JTA,
> but if a cache store can, we should definitely support it.
Why "definitely" ? It's of course nice to have, but I'm not sure of
the actual value.
the cache store is an extension of ISPN's internal storage,
so if it isn't JTA compliant then ISPN configured with a cache store, as a whole, is
not JTA compliant.
If we're planning to include a guarantee of storage in the cacheloader
before the cache operation returns, that means the cacheloader can't
be configured as write-behind, correct?
Now if the CacheLoader is not in write-behind, and it's a different
resource than the Cache itself, I see not much value in it since I
could write in both the cache and the cacheloader from user code
directly, if I needed this functionality.
That depends on your consistency
requirement. If you require (JTA) transactions then write behind simply doesn't give
you the consistency guarantees you're after. You could indeed write in the store and
cache directly from user code and then check the cache but we already do this for you :-)
as I see it, the biggest values of a CacheLoader are:
- to have the cache load from it
- write-behind with coaleshing and batching
which don't sound like it needs to participate in the same transaction
as the Cache operations. It could still use transaction to sync cache
and CacheLoader, but that's possible without changing the interface.
And the current limitations:
- it' s hard to have it "translate" from - taking JDBC for example -
an existing schema. (Or - for example - store the Lucene index in it's
native format on disk)
- not sure we can create a generic enough JDBC cache store
that would map to any schema, I think custom impls are the way to go here.
- doesn't have a "remove expired" function, needs to
load all values
to check them
- that's cache store specific.
- no way to list all keys without loading the values
- totally no support for MVCC
- not sure what you mean by that.. better support for
storing the version perhaps?
Imho these are more usefull, unless I'm totally missing what's the
intention of JTA participation ?
>> Mind detailing a bit on the batching/colaesce functionality you have in mind?
> Actually I wasn't thinking about anything more complex than what we have
> already with the applyModifications() call (which in fact could be
> reused), but my understanding is that this is only called in
> transactional cache operations ? For example the AsyncStore applies
> lists modifications internally, without delegating to the cachestore's
> implementation.
>
> Tristan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:06 a.m.
On 2 Apr 2012, at 14:57, Mircea Markus wrote:
On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
> On 2 April 2012 14:31, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
>> On 04/02/2012 03:17 PM, Mircea Markus wrote:
>>> On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
>>>
>>>> I dislike the current way of configuring stores via<property>. As
part of my work for ISPN-1821 I will also introduce the ability for stores to provide
their own configuration parsers so that we can have more readable schemas.
>>> That would be quite nice, as the property-based approach is very error prone.
Curious how you're going to support 'dynamic' xml snippets,through some xml
name spaces perhaps?
>> Yes, just like the Spring configuration or even the AS7 configuration
>> itself. In XSD speak they would be complex-types extending a generic
>> "store" type.
>
> +1, same for the Query options: <properties /> is limiting.
>
>>>> Participating in JTA is obviously high on the desired list, and I'd
also expose some form of batching so that intelligent cache-store can colaesce operations
together for better performance.
>>> that's a big one indeed. JTA support won't be available for all
stores, e.g. cloud cache store.
>> I think very few stores would have the ability to participate in JTA,
>> but if a cache store can, we should definitely support it.
>
> Why "definitely" ? It's of course nice to have, but I'm not sure
of
> the actual value.
the cache store is an extension of ISPN's internal storage, so if it isn't JTA
compliant then ISPN configured with a cache store, as a whole, is not JTA compliant.
Not true. If Infinispan acts as a JTA proxy (which is what it currently does), then it
still is JTA compliant.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
9:16 a.m.
On 2 Apr 2012, at 15:06, Manik Surtani wrote:
On 2 Apr 2012, at 14:57, Mircea Markus wrote:
>
> On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
>
>> On 2 April 2012 14:31, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
>>> On 04/02/2012 03:17 PM, Mircea Markus wrote:
>>>> On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
>>>>
>>>>> I dislike the current way of configuring stores via<property>.
As part of my work for ISPN-1821 I will also introduce the ability for stores to provide
their own configuration parsers so that we can have more readable schemas.
>>>> That would be quite nice, as the property-based approach is very error
prone. Curious how you're going to support 'dynamic' xml snippets,through some
xml name spaces perhaps?
>>> Yes, just like the Spring configuration or even the AS7 configuration
>>> itself. In XSD speak they would be complex-types extending a generic
>>> "store" type.
>>
>> +1, same for the Query options: <properties /> is limiting.
>>
>>>>> Participating in JTA is obviously high on the desired list, and
I'd also expose some form of batching so that intelligent cache-store can colaesce
operations together for better performance.
>>>> that's a big one indeed. JTA support won't be available for all
stores, e.g. cloud cache store.
>>> I think very few stores would have the ability to participate in JTA,
>>> but if a cache store can, we should definitely support it.
>>
>> Why "definitely" ? It's of course nice to have, but I'm not
sure of
>> the actual value.
> the cache store is an extension of ISPN's internal storage, so if it isn't
JTA compliant then ISPN configured with a cache store, as a whole, is not JTA compliant.
Not true. If Infinispan acts as a JTA proxy (which is what it currently does), then it
still is JTA compliant.
Not sure what you mean by JTA proxy? ISPN is a fully flagged
XAResource, but when you use a non-JTA cache store inconsistencies can occur ( not aCid
transactions).
9:16 a.m.
On 2 April 2012 14:57, Mircea Markus <mircea.markus(a)jboss.com> wrote:
On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
> On 2 April 2012 14:31, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
>> On 04/02/2012 03:17 PM, Mircea Markus wrote:
>>> On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
>>>
>>>> I dislike the current way of configuring stores via<property>. As
part of my work for ISPN-1821 I will also introduce the ability for stores to provide
their own configuration parsers so that we can have more readable schemas.
>>> That would be quite nice, as the property-based approach is very error prone.
Curious how you're going to support 'dynamic' xml snippets,through some xml
name spaces perhaps?
>> Yes, just like the Spring configuration or even the AS7 configuration
>> itself. In XSD speak they would be complex-types extending a generic
>> "store" type.
>
> +1, same for the Query options: <properties /> is limiting.
>
>>>> Participating in JTA is obviously high on the desired list, and I'd
also expose some form of batching so that intelligent cache-store can colaesce operations
together for better performance.
>>> that's a big one indeed. JTA support won't be available for all
stores, e.g. cloud cache store.
>> I think very few stores would have the ability to participate in JTA,
>> but if a cache store can, we should definitely support it.
>
> Why "definitely" ? It's of course nice to have, but I'm not sure
of
> the actual value.
the cache store is an extension of ISPN's internal storage, so if it isn't JTA
compliant then ISPN configured with a cache store, as a whole, is not JTA compliant.
>
> If we're planning to include a guarantee of storage in the cacheloader
> before the cache operation returns, that means the cacheloader can't
> be configured as write-behind, correct?
>
> Now if the CacheLoader is not in write-behind, and it's a different
> resource than the Cache itself, I see not much value in it since I
> could write in both the cache and the cacheloader from user code
> directly, if I needed this functionality.
That depends on your consistency requirement. If you require (JTA) transactions then
write behind simply doesn't give you the consistency guarantees you're after. You
could indeed write in the store and cache directly from user code and then check the cache
but we already do this for you :-)
>
> as I see it, the biggest values of a CacheLoader are:
> - to have the cache load from it
> - write-behind with coaleshing and batching
>
> which don't sound like it needs to participate in the same transaction
> as the Cache operations. It could still use transaction to sync cache
> and CacheLoader, but that's possible without changing the interface.
>
> And the current limitations:
> - it' s hard to have it "translate" from - taking JDBC for example -
> an existing schema. (Or - for example - store the Lucene index in it's
> native format on disk)
- not sure we can create a generic enough JDBC cache store that would map to any schema,
I think custom impls are the way to go here.
Sure, but even then if you try implementing a custom one it's not easy
as you might need some more context or be able to remote-get more keys
than what you are being passed; a problem I had is the CacheLoader is
not able to load additional keys it might need to assemble some
complex structure which is stored as multiple entries, especially if
the CacheLoader is not shared, as the needed key might not be
available in the store itself.
> - doesn't have a "remove expired" function, needs
to load all values
> to check them
- that's cache store specific.
> - no way to list all keys without loading the values
> - totally no support for MVCC
- not sure what you mean by that.. better support for storing the version perhaps?
Yes, I think we'll need them; didn't think it much through, but
operations like "purge values before version", or load(key, version),
etc..
In database terms, storing the version at all would be a good start.
>
> Imho these are more usefull, unless I'm totally missing what's the
> intention of JTA participation ?
>
>>> Mind detailing a bit on the batching/colaesce functionality you have in
mind?
>> Actually I wasn't thinking about anything more complex than what we have
>> already with the applyModifications() call (which in fact could be
>> reused), but my understanding is that this is only called in
>> transactional cache operations ? For example the AsyncStore applies
>> lists modifications internally, without delegating to the cachestore's
>> implementation.
>>
>> Tristan
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:07 a.m.
Captured in https://community.jboss.org/wiki/CacheLoaderAndCacheStoreSPIRedesign
Please add any further thoughts to the wiki.
On 2 Apr 2012, at 15:17, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 2 April 2012 14:57, Mircea Markus <mircea.markus(a)jboss.com>
wrote:
>
> On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
>
>> On 2 April 2012 14:31, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
>>> On 04/02/2012 03:17 PM, Mircea Markus wrote:
>>>> On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
>>>>
>>>>> I dislike the current way of configuring stores via<property>.
As part of my work for ISPN-1821 I will also introduce the ability for stores to provide
their own configuration parsers so that we can have more readable schemas.
>>>> That would be quite nice, as the property-based approach is very error
prone. Curious how you're going to support 'dynamic' xml snippets,through some
xml name spaces perhaps?
>>> Yes, just like the Spring configuration or even the AS7 configuration
>>> itself. In XSD speak they would be complex-types extending a generic
>>> "store" type.
>>
>> +1, same for the Query options: <properties /> is limiting.
>>
>>>>> Participating in JTA is obviously high on the desired list, and
I'd also expose some form of batching so that intelligent cache-store can colaesce
operations together for better performance.
>>>> that's a big one indeed. JTA support won't be available for all
stores, e.g. cloud cache store.
>>> I think very few stores would have the ability to participate in JTA,
>>> but if a cache store can, we should definitely support it.
>>
>> Why "definitely" ? It's of course nice to have, but I'm not
sure of
>> the actual value.
> the cache store is an extension of ISPN's internal storage, so if it isn't
JTA compliant then ISPN configured with a cache store, as a whole, is not JTA compliant.
>
>>
>> If we're planning to include a guarantee of storage in the cacheloader
>> before the cache operation returns, that means the cacheloader can't
>> be configured as write-behind, correct?
>>
>> Now if the CacheLoader is not in write-behind, and it's a different
>> resource than the Cache itself, I see not much value in it since I
>> could write in both the cache and the cacheloader from user code
>> directly, if I needed this functionality.
> That depends on your consistency requirement. If you require (JTA) transactions then
write behind simply doesn't give you the consistency guarantees you're after. You
could indeed write in the store and cache directly from user code and then check the cache
but we already do this for you :-)
>
>>
>> as I see it, the biggest values of a CacheLoader are:
>> - to have the cache load from it
>> - write-behind with coaleshing and batching
>>
>> which don't sound like it needs to participate in the same transaction
>> as the Cache operations. It could still use transaction to sync cache
>> and CacheLoader, but that's possible without changing the interface.
>>
>> And the current limitations:
>> - it' s hard to have it "translate" from - taking JDBC for example
-
>> an existing schema. (Or - for example - store the Lucene index in it's
>> native format on disk)
> - not sure we can create a generic enough JDBC cache store that would map to any
schema, I think custom impls are the way to go here.
Sure, but even then if you try implementing a custom one it's not easy
as you might need some more context or be able to remote-get more keys
than what you are being passed; a problem I had is the CacheLoader is
not able to load additional keys it might need to assemble some
complex structure which is stored as multiple entries, especially if
the CacheLoader is not shared, as the needed key might not be
available in the store itself.
>> - doesn't have a "remove expired" function, needs to load all
values
>> to check them
> - that's cache store specific.
>> - no way to list all keys without loading the values
>> - totally no support for MVCC
> - not sure what you mean by that.. better support for storing the version perhaps?
Yes, I think we'll need them; didn't think it much through, but
operations like "purge values before version", or load(key, version),
etc..
In database terms, storing the version at all would be a good start.
>>
>> Imho these are more usefull, unless I'm totally missing what's the
>> intention of JTA participation ?
>>
>>>> Mind detailing a bit on the batching/colaesce functionality you have in
mind?
>>> Actually I wasn't thinking about anything more complex than what we have
>>> already with the applyModifications() call (which in fact could be
>>> reused), but my understanding is that this is only called in
>>> transactional cache operations ? For example the AsyncStore applies
>>> lists modifications internally, without delegating to the cachestore's
>>> implementation.
>>>
>>> Tristan
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:06 a.m.
On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
- doesn't have a "remove expired" function, needs to
load all values
to check them
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
9:10 a.m.
On 2 April 2012 15:06, Manik Surtani <manik(a)jboss.org> wrote:
On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
- doesn't have a "remove expired" function, needs to load all values
to check them
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
great, thanks :-) Wasn't there last I needed it!
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:55 a.m.
On Apr 2, 2012, at 3:17 PM, Mircea Markus wrote:
On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
> I dislike the current way of configuring stores via <property>. As part of my
work for ISPN-1821 I will also introduce the ability for stores to provide their own
configuration parsers so that we can have more readable schemas.
That would be quite nice, as the property-based approach is very error prone. Curious how
you're going to support 'dynamic' xml snippets,through some xml name spaces
perhaps?
@Mircea, see AS7 configuration, they're precisely doing this with each subsystem's
configuration.
>
> Participating in JTA is obviously high on the desired list, and I'd also expose
some form of batching so that intelligent cache-store can colaesce operations together for
better performance.
that's a big one indeed. JTA support won't be available for all stores, e.g.
cloud cache store.
Mind detailing a bit on the batching/colaesce functionality you have in mind?
>
> Maybe the ability to introduce some form of compression for values (if over a certain
size threshold).
I don't think that would require a API change, as this sort of behaviour seem to be
orthogonal and can be handled to a wrapper CacheStore implementation, very much like the
AsyncCache store. Might require a configuration change though. Also I think this is a good
task for an external contributor.
_______________________________________________
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
9:54 a.m.
On Apr 2, 2012, at 3:02 PM, Tristan Tarrant wrote:
I dislike the current way of configuring stores via <property>.
As part of my work for ISPN-1821 I will also introduce the ability for stores to provide
their own configuration parsers so that we can have more readable schemas.
^ What kind of timeline do you have for that? I've been having a fair few issues with
https://issues.jboss.org/browse/ISPN-1924 due to cache stores been mainly configured the
old way (i.e. they expect an old config object in the interface). So, let's synch up
to know which is going to be ready first.
Participating in JTA is obviously high on the desired list, and I'd also expose some
form of batching so that intelligent cache-store can colaesce operations together for
better performance.
^ We're alread coalescing operations in async, but I guess you're talking about
the cache store being to apply a list of modifications in a cache store specific way? The
async store these days just loops through the list and delegates.
I think your suggestion would fit nicely with the coalescing work done now.
Maybe the ability to introduce some form of compression for values (if over a certain
size threshold).
Tristan
As part of the work I'm doing for ISPN-1821 (being able to parse AS configurations in
Infinispan), I
On 04/02/2012 02:47 PM, Manik Surtani wrote:
> I know this is much needed, and perhaps 6.0 may be the time to do this. Do we have a
list of things we want to change here?
>
> On the back of https://community.jboss.org/message/726337#726337 it would seem that
we need the ability to pass in the ConsistentHash to the CacheLoader when loading entries,
so that if the cache store is shared, it can selectively load entries targeted to the node
in question. Either that, or to be able to call CacheLoader.load(CacheLoaderFilter) where
CacheLoaderFilter would expose a shouldLoad(Object key).
>
> Other thoughts include better JTA integration, etc?
>
> Cheers
> Manik
> --
> Manik Surtani
> manik(a)jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
>
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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
5:12 a.m.
On 10 Apr 2012, at 15:54, Galder Zamarreño wrote:
^ What kind of timeline do you have for that? I've been having a
fair few issues withhttps://issues.jboss.org/browse/ISPN-1924 due to cache stores been
mainly configured the old way (i.e. they expect an old config object in the interface).
So, let's synch up to know which is going to be ready first.
For 6.0, unfortunately. But do capture your thoughts on the design wiki.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
6:34 a.m.
I've started playing around with the redesigned interfaces here:
https://github.com/maniksurtani/infinispan-cachestore-proposal
Please have a look and comment on the wiki.
On 11 Apr 2012, at 11:12, Manik Surtani wrote:
On 10 Apr 2012, at 15:54, Galder Zamarreño wrote:
> ^ What kind of timeline do you have for that? I've been having a fair few issues
withhttps://issues.jboss.org/browse/ISPN-1924 due to cache stores been mainly configured
the old way (i.e. they expect an old config object in the interface). So, let's synch
up to know which is going to be ready first.
For 6.0, unfortunately. But do capture your thoughts on the design wiki.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
8:11 a.m.
I've added my comments there - from my experience the mailing list is a better fit for
this kind conversation though.
On 11 Apr 2012, at 12:34, Manik Surtani wrote:
I've started playing around with the redesigned interfaces here:
https://github.com/maniksurtani/infinispan-cachestore-proposal
Please have a look and comment on the wiki.
On 11 Apr 2012, at 11:12, Manik Surtani wrote:
>
> On 10 Apr 2012, at 15:54, Galder Zamarreño wrote:
>
>> ^ What kind of timeline do you have for that? I've been having a fair few
issues withhttps://issues.jboss.org/browse/ISPN-1924 due to cache stores been mainly
configured the old way (i.e. they expect an old config object in the interface). So,
let's synch up to know which is going to be ready first.
>
> For 6.0, unfortunately. But do capture your thoughts on the design wiki.
>
>
> --
> Manik Surtani
> manik(a)jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:07 a.m.
Btw, a few months back I saw this forum post: https://community.jboss.org/thread/171515
The guy's considering implementing cache loader and it's a bit confused with all
methods that need to implement, and points to Coherence's cache loader interface which
simply has 2 methods:
http://download.oracle.com/otn_hosted_doc/coherence/330/com/tangosol/net/...
And cache store has just 4 methods:
http://download.oracle.com/otn_hosted_doc/coherence/330/com/tangosol/net/...
I haven't checked what the JSR-107 interfaces look like but let's try to keep
things simple.
On Apr 2, 2012, at 2:47 PM, Manik Surtani wrote:
I know this is much needed, and perhaps 6.0 may be the time to do
this. Do we have a list of things we want to change here?
On the back of https://community.jboss.org/message/726337#726337 it would seem that we
need the ability to pass in the ConsistentHash to the CacheLoader when loading entries, so
that if the cache store is shared, it can selectively load entries targeted to the node in
question. Either that, or to be able to call CacheLoader.load(CacheLoaderFilter) where
CacheLoaderFilter would expose a shouldLoad(Object key).
Other thoughts include better JTA integration, etc?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
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
1:34 p.m.
Seems pretty much the same as the Coherence one:
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
I'm not sure where you're supposed the keys from in order to do any
preloading, so maybe we still need another method to load random
entries.
I'd remove loadAllKeys, I think state transfer can just assume that
entries on disk are not in memory when passivation and that entries on
disk are also in memory when passivation is disabled (so no need for a
memory-only state transfer).
containsKey is only used when removing keys and most cache stores can
remove stuff without the extra check, so that should probably go as
well - although it's probably one of the more straightforward methods
:)
In CacheStore, the toStream and fromStream methods aren't even used
any more (used to be called by state transfer).
Cheers
Dan
On Tue, Apr 10, 2012 at 6:07 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
Btw, a few months back I saw this forum post:
https://community.jboss.org/thread/171515
The guy's considering implementing cache loader and it's a bit confused with all
methods that need to implement, and points to Coherence's cache loader interface which
simply has 2 methods:
http://download.oracle.com/otn_hosted_doc/coherence/330/com/tangosol/net/...
And cache store has just 4 methods:
http://download.oracle.com/otn_hosted_doc/coherence/330/com/tangosol/net/...
I haven't checked what the JSR-107 interfaces look like but let's try to keep
things simple.
On Apr 2, 2012, at 2:47 PM, Manik Surtani wrote:
> I know this is much needed, and perhaps 6.0 may be the time to do this. Do we have a
list of things we want to change here?
>
> On the back of https://community.jboss.org/message/726337#726337 it would seem that
we need the ability to pass in the ConsistentHash to the CacheLoader when loading entries,
so that if the cache store is shared, it can selectively load entries targeted to the node
in question. Either that, or to be able to call CacheLoader.load(CacheLoaderFilter) where
CacheLoaderFilter would expose a shouldLoad(Object key).
>
> Other thoughts include better JTA integration, etc?
>
> Cheers
> Manik
> --
> Manik Surtani
> manik(a)jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
> _______________________________________________
> 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:12 a.m.
On 10 Apr 2012, at 19:34, Dan Berindei wrote:
In CacheStore, the toStream and fromStream methods aren't even used
any more (used to be called by state transfer).
Good, pls capture this on the design wiki.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
4924
days inactive
4933
days old
infinispan-dev@lists.jboss.org
19 comments
7 participants
participants (7)
-
Dan Berindei -
Galder Zamarreño -
Manik Surtani -
Manik Surtani -
Mircea Markus -
Sanne Grinovero -
Tristan Tarrant