Re: [infinispan-dev] Module configuration proposal
by Manik Surtani
Essentially, modules are internal constructs that we use to make the
codebase more manageable. End users shouldn't need to know or care
whether a feature is in a separate module or not. To some degree the
end user is aware of some separation (different jars to add) but that
should be the extent of exposure. :)
That is the ideal setup of course.
Sent from my iPhone
On 6 Nov 2009, at 14:58, Manik Surtani <manik(a)jboss.org> wrote:
> <infinispan>
> <namedCache name="blah">
> <indexing enabled="true" localOnly="false" />
> </>
> </>
>
> Sent from my iPhone
>
> On 6 Nov 2009, at 14:18, Vladimir Blagojevic <vblagoje(a)redhat.com>
> wrote:
>
>> On 09-11-06 6:37 AM, Manik Surtani wrote:
>>> A couple of comments re 193:
>>>
>>> How would you set this stuff programmatically? Conf.setQueryConfig
>>> (qc) ?
>>>
>>> Also, are the<module> tags and the<query:> prefix necessary in the
>>> XML config? Any clever way to do without these, since the
>>> queryconfig
>>> bean is detected at the beginning and doesn't have to be loaded when
>>> specific tags are encountered, right?
>>>
>>> Cheers
>>> Manik
>>>
>> We can make it programmatic, no problem.
>>
>> Prefix, we have to keep since JAXB forces it. We can avoid its usage
>> if we manually change generated schema.
>>
>> How would you ideally align these tags?
>>
>> _______________________________________________
>> 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
14 years, 12 months
Cache entry not invalidated callback?
by Galder Zamarreno
Hi,
Re: Porting over
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818 to
Infinispan 2nd level cache.
For HHH-3818, Brian used the cache as a bus to notify that the cache
contents where invalid. To do so, he implemented cache entry modified
and invalidated callbacks that react to cache modifications or
invalidations where the FQN is an internal fqn which contains the local
address.
Now, the trick he uses for the invalidation is that on startup or
whenever there's a view change, he establishes these internal FQNs in
each node for each of the members in the cluster, i.e.
fqn=/test/com/foo/test/ENTITY/NODE/127.0.0.1:39104
So, in an invalidation scenario, if you a node puts something on
/test/com/foo/test/ENTITY/NODE/127.0.0.1:39104, the other nodes have at
least /test/com/foo/test/ENTITY/NODE/127.0.0.1:39104 created on their
caches which means that the invalidation callback works fine cos the FQN
exists in other nodes.
Now, in Infinispan's case, bearing in mind that there're no FQNs, I
could set up such keys when there's a view change too. However, I was
thinking of another alternative.
Currently, cache invalidation callback fails on Infinispan because when
you do a put on key=127.0.0.1:39104, the other nodes do not contain the
key=127.0.0.1:39104, so no invalidation callback is received. So, my
suggestion is the following:
Why not have a callback saying: "I attempted to do an invalidation on
k=x but k=x did not exist". Maybe something like
CacheEntryNotInvalidated callback? It looks to me that it'd be
relatively simply to implement such notification and would simplify the
code on the Infinispan 2nd level cache provider.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 12 months
Making confusion between different remove() APIs
by Sanne Grinovero
Hello,
I was writing this code:
boolean cleared = cache.remove(key);
and then I'd thought "let's add a Flag", resulting in:
boolean cleared = cache.remove(key, Flag.SKIP_CACHE_STORE);
Considering that CacheDelegate contains the following 3 overloaded
"remove" methods:
====== CacheDelegate<K,V> ======
public final boolean remove(Object key, Object value) {
return remove(key, value, (Flag[]) null);
}
public final boolean remove(Object key, Object oldValue, Flag... flags) {
...
}
public final V remove(Object key, Flag... flags) {
...
}
====== end code snippet ======
Guess which one is called?
The first one, interpreting my Flag as a value, and obviously my code
was broken.
It's fixed by using:
cache.remove(keyOfLock, new Flag[]{Flag.SKIP_CACHE_STORE});
IMHO it's quite bad already that the CHM has different remove
variants, one returning the previous object and one returning a
boolean "removed or not removed", but this API in Infinispan is making
it even harder.
It would be safer to mandate the array form for Flags, even if I don't
like that; do you have a better idea?
Regards,
Sanne
15 years
jclouds sneak preview: cloud interop and twitter
by Adrian Cole
While jclouds specializes in cloud storage, it also is capable of
connecting to any ReST service (like twitter).
To show this point, I've created a demo sneak-previewing the pending
beta-3 of jclouds. This demo runs in google appengine and copies
tweets into 3 storage clouds using the new portable blobstore api.
More details and link here: http://bit.ly/3QFN66
beta-3 will be out in the next couple of days. Make sure you are
following jclouds on twitter so you don't miss the news!
Cheers,
-Adrian
founder jclouds
http://code.google.com/p/jclouds/
http://twitter.com/jclouds
15 years
