JBoss R&D Laboratory in Brno | 2 Infinispan related projects
by Tomas Sykora
Hello Infinispan community,
I'm bringing good news for us. Currently, we are starting JBoss R&D Laboratory at Faculty of Informatics (Masaryk University, Brno). We are hoping that our initiative will bring new contributors to Infinispan projects -- mainly students from local Universities.
You can learn more about the LAB and project proposals at: https://developer.jboss.org/wiki/JBossRDLabAtFIMUNI
If you have ANY ideas, proposals, concerns or just comments -- share them please.
I will keep you informed!
Tomas
9 years
Eventing mechanism and ordering
by Pierre Sutra
Hello,
I have run some tests regarding the ordering properties of the clustered
eventing mechanism in Infinispan
(https://gist.github.com/otrack/0b67dcdae61bb83e0da3).
When transaction are set to false, clustered listeners receive events in
the same order, as expected. Yet, this is not the case when transactions
are available. I would like to know whether this behavior is expected,
or not, as the documentation does not precise it.
Cheers,
Pierre
9 years
Relaxing clear semantics
by Pedro Ruivo
Hi guys,
I'm going to start working on the new relaxed clear semantic (in the
context of ISPN-4140). It affects, at least, the following JIRA:
ISPN-4073: clear() can create inconsistencies
ISPN-3656: Relax Cache.clear() semantics
ISPN-4778: PessimisticLockingInterceptor throws when handling remote
clear command
ISPN-4140: Clear command doesn't acquire any remote locks in pessimistic
mode
ISPN-2849: Don't keep threads blocked when waiting for locks to be released
In short, the semantic would be: "it clears the cache. If any concurrent
operation is in progress, the result is undetermined".
So, if concurrent operation can put the cache in inconsistent state. But
in other hand, I don't see any case in which a clear is needed during
production...
In transactional cache, the clear will not affect the transaction. Also,
it will not acquire any locks in LockManager. Why?
First, we assume that no other operation is in progress, second, if the
first assumption is wrong, it can cause deadlocks with it, and third, it
would avoid creating a global lock.
Any other concerns?
Cheers,
Pedro
9 years, 1 month
Multi get API
by William Burns
I am nearing completion of the new multi get command [1], allowing for
more efficient retrieval of multiple keys at the same time. Thanks
again to Radim for a lot of the initial work.
In doing so though I want to make sure I get feedback on how we want
the API to actually look, since this is much more difficult to change
down the line.
There are a few things in particular I wanted to discuss.
1. The actual name of the method. The main suggestions I have seen
are getAll or getMany. I do like the naming of the former, however it
seems a bit misleading (remember API is getAll(Set) since we are
really getting a subset. So I am thinking the possibilities at this
point are getAllOf, getAllFor or getMany. I am leaning maybe towards
the last one (getMany). I am open to any suggestions though.
2. What should the return value be for this method. Currently this
returns a Map<K, V> which makes sense when we retain these values in
the local transactional context and is pretty nice and clean for end
users.
The other idea is to use a streaming API possibly returning an
Iterable<CacheEntry<K, V>>. The streaming return value doesn't seem
as intuitive to me, but opens us up for more efficient usage
especially when there may be a lot of keys passed in (also results can
be processed concurrently while retrieval is still occurring).
I would lean towards returning the Map<K, V> value, however the next
point could change that.
3. Where this method should live. Right now this method is on the
BasicCache interface which is a parent of both Cache (embedded) and
RemoteCache (remote). Unfortunately for remote clients to be as
efficient as possible we really need a Streaming API so that we don't
have multiple copies of data in memory at multiple places at the same
time. For that reason I suggest we use the streaminig API for both or
have a different API for remote vs embedded.
Let me know what you guys think.
Cheers,
- Will
[1] https://issues.jboss.org/browse/ISPN-2183
9 years, 1 month
