Data container resizing
by Tristan Tarrant
Hi all,
Sebastian recently added BCHMV8 resizing and I'm now hooking it up to configuratiombean jmx and server. I wanted your opinion on some details.
- configuration: easy, register a listener with the attribute so that invoking configuration.eviction().size (newSize) does a resize of the data container
- server already exposes the size in the management model, we just need to change its behaviour so that the change is "live". In this context the change is also persisted to the xml configuration
- Jmx: do we want a writable "capacity" attribute or a resize operation? And do we want it on the cache mbean or on a new data container mbean? And should the change affect the configuration object too, i.e. invoking configuration.eviction().size () should return the new value? For symmetry with server we should.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss a division of Red Hat
9 years, 12 months
Lambda's & Batching
by Sanne Grinovero
A local cache with batching enabled produces this:
java.lang.IllegalArgumentException: Cannot create a transactional
context without a valid Transaction instance.
at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
(<-- experimental uncommitted code here)
I'm guessing the eval implementations is needing the
"auto-transaction-start" semantics which we normally have for other
operations in a batching cache... right?
But I wonder about the usefulness of having a short lived batching
context when all I'm doing is sending a lambda to a specific entry:
wouldn't it be even better to treat this as a no-context operation?
Thanks,
Sanne
10 years
