On Jun 28, 2013, at 5:16 PM, Radim Vansa rva...@redhat.com wrote:
Hi,
I was playing with efficient ways to write to append-only log and I have some
results below.
I've used three implementations: one simply synchronizing the access and
calling force(false) after each write (by default
On Jul 2, 2013, at 3:32 PM, Radim Vansa rva...@redhat.com wrote:
| Given such a scenario, I am not interested at all in synchronous
| storage. Before we commit into a design which is basically assuming
| the need for synchronous storage guarantees, I'd like to understand
| what kind of use
I went through Loaders and Stores JIRAs and I don't see anything that should
handle the overall node-restart/cluster-restart scenario with DIST + local
cachestore.
We have two situations to happen: single-node failure followed by a restart and
cluster-failure/shutdown followed by retrieval
|
| I've used three implementations: one simply synchronizing the access and
| calling force(false) after each write (by default 1kB). Second with
| threads cooperating - every thread puts its data into queue and waits for
| a short period of time - if then its data are still in the queue,
On Tue, Jul 2, 2013 at 8:41 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 2 July 2013 17:24, Dan Berindei dan.berin...@gmail.com wrote:
It's not wrong, sending the invalidation only from the primary owner is
wrong :)
Agreed, sending a GET operation to multiple nodes might not be wrong
On Tue, Jul 2, 2013 at 9:51 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 07/02/2013 04:55 PM, Dan Berindei wrote:
On Tue, Jul 2, 2013 at 6:35 PM, Pedro Ruivo pe...@infinispan.org
mailto:pe...@infinispan.org wrote:
On 07/02/2013 04:29 PM, Dan Berindei wrote:
Sanne, let me comment on some of the points you raised that didn't comment on
in an earlier comment...
On Jul 2, 2013, at 2:47 PM, Sanne Grinovero sa...@infinispan.org wrote:
It would be nice to have a deck of cheat sheets on the expected use
cases and guarantees: to me it looks like everyone
Hi Galder,
you make many interesting points but I am not interested in discussing
my specific design ideas in detail, I just sketched that quickly as an
example of requirements description.
My intervention in this thread is all about demanding what the use
case is for such a synchronous
