On 9 Jun 2011, at 20:39, Manik Surtani wrote:
> Regarding the comment on transactional versus non-transactional threads
> mentioned on https://issues.jboss.org/browse/ISPN-1137 - I think the fact
> that we allow this is a flaw.
>
> The approach we are taking with JSR 107 is such:
>
> 1) If a
Yes, I know its odd that it relates to a sub-module but has to live in core. I
agree that the flag is useful though. I vote lets keep it in.
On 16 Jun 2011, at 19:48, Sanne Grinovero wrote:
> Hello all,
> I was having a quick look into
> https://issues.jboss.org/browse/ISPN-1179
>
> to see if
On 10 Jun 2011, at 13:42, Manik Surtani wrote:
> So I've taken on this sub-task from Sanne (ISPN-1169), and here is the deal:
>
> BCHM analyses whether or not to evict stuff every time an operation (put,
> get, replace) is run, based on the configured eviction policy (LIRS, LRU or
> NONE). It
>
>> 2) with async stores, the issue is back. The value is not going to be
>> found while it's "in flight" in the async storage queue; so unless you
>> want to avoid supporting it for now, the actual removal from the
>> container should be performed from the async cache loader code.
>
> Ugh - ye
On 17 Jun 2011, at 11:09, Mircea Markus wrote:
>
>>
>>> 2) with async stores, the issue is back. The value is not going to be
>>> found while it's "in flight" in the async storage queue; so unless you
>>> want to avoid supporting it for now, the actual removal from the
>>> container should be p
On 17 Jun 2011, at 11:03, Mircea Markus wrote:
>>
>> 2) EvictionStrategies ensure passivation occurs *before* removing an entry
>> from the BCHM
> Does this cover the following scenario?
> 1. thread1.get determines that K needs to be passivated
> 2. thread2 remove(k) removes it from memory
> 3
On 9 Jun 2011, at 15:26, Manik Surtani wrote:
> We use partial state transfer not to generate partial state per cache, but
> the entire state per cache, but since we have > 1 cache sharing a given
> JGroups channel, as far as JGroups in concerned this *is* partial state of a
> node. I.e., th
On 6/17/11 2:49 PM, Mircea Markus wrote:
> Now this might sound a bit too radical but do we really need REPLICATED mode?
> This is not fully brewed, but if e.g. we set numOwners = Integer.MAX_INTEGER
> the cluster is effectively in replicated mode, so can't we just drop the
> REPLICATION enti
On 17 Jun 2011, at 14:51, Bela Ban wrote:
>
>
> On 6/17/11 2:49 PM, Mircea Markus wrote:
>
>
>> Now this might sound a bit too radical but do we really need REPLICATED mode?
>> This is not fully brewed, but if e.g. we set numOwners = Integer.MAX_INTEGER
>> the cluster is effectively in repli
On Wed, 2011-06-01 at 16:46 +0200, Bela Ban wrote:
>
> On 6/1/11 4:21 PM, Sanne Grinovero wrote:
> > Hi Bela,
> >
> > 2011/6/1 Bela Ban:
> >> We currently use JGroups' partial state transfer to transfer individual
> >> caches from one Infinispan instance to another.
> >>
> >> Since I got rid of pa
10 matches
Mail list logo
