On Dec 12, 2011, at 3:45 AM, Mircea Markus wrote:
On 10 Dec 2011, at 10:04, Pete Muir wrote:
https://issues.jboss.org/browse/ISPN-1474
Currently we do a mix of:
enableXXX()
disableXXX()
enabled(boolean b)
XXX(boolean b)
where XXX is something to enable or disable (e.g.
I think Manik is referring to the fact that ISPN's MVCC implementation does
not guarantee serializability.
yes.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1556
Re: https://github.com/infinispan/infinispan/pull/719/files#r288994
The fix I suggest works well with explicit transactions, but if we leave this
as is, implicit txs might leak transactions. The reason is because if we allow
a put with
On Tue, Dec 13, 2011 at 10:44 AM, Galder Zamarreño gal...@redhat.com wrote:
On Dec 12, 2011, at 3:45 AM, Mircea Markus wrote:
On 10 Dec 2011, at 10:04, Pete Muir wrote:
https://issues.jboss.org/browse/ISPN-1474
Currently we do a mix of:
enableXXX()
disableXXX()
enabled(boolean b)
On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
Why would you avoid FORCE_WRITE_LOCK ?
Does the following make sense?
tx.begin()
cache.withFlags(FORCE_WRITE_LOCK).get(…)
tx.commit()
It doesn't in my view. You force a write lock to then to something within a
transaction with the
I use the pattern:
tx.begin();
cache1.lock();
...
tx.commit();
There are other caches involved in the transaction, but cache1 doesn't
actually put any data. It's just there so I don't have to acquire 8-13
explicit locks on the other caches. Improved throughput in my application.
I also use
Hi,
I guess I will troll a little here but it seems to me that the
implicit transactions are the issue.
What Galder suggested does makes sense( that you would want a failure
to put in the cache in some circumstances to have no incidence) but
some times if too many things are telling something
On Dec 13, 2011, at 3:00 PM, Sanne Grinovero wrote:
On 13 December 2011 13:48, Galder Zamarreño gal...@redhat.com wrote:
On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
Why would you avoid FORCE_WRITE_LOCK ?
Does the following make sense?
tx.begin()
On Dec 13, 2011, at 3:12 PM, Erik Salter wrote:
I use the pattern:
tx.begin();
cache1.lock();
...
tx.commit();
Right, but that pattern is not implicit tx where each cache operation is
surrounded internally by a transaction.
You are doing explicit or external tx management which is not
On Dec 13, 2011, at 4:04 PM, Slorg1 wrote:
Hi,
I guess I will troll a little here but it seems to me that the
implicit transactions are the issue.
What Galder suggested does makes sense( that you would want a failure
to put in the cache in some circumstances to have no incidence) but
Hi,
On Tue, Dec 13, 2011 at 12:08, Galder Zamarreño gal...@redhat.com wrote:
On Dec 13, 2011, at 4:04 PM, Slorg1 wrote:
Hi,
I guess I will troll a little here but it seems to me that the
implicit transactions are the issue.
What Galder suggested does makes sense( that you would want a
Hi,
OMG, I've just counted 23 constructors in RemoteCacheManager! Do we really need
them all?
http://docs.jboss.org/infinispan/5.1/apidocs/org/infinispan/client/hotrod/RemoteCacheManager.html
Something to cleanup in 6.0…
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss
I believe a fair few will be removed, yes.
On 13 Dec 2011, at 17:17, Galder Zamarreño wrote:
Hi,
OMG, I've just counted 23 constructors in RemoteCacheManager! Do we really
need them all?
13 matches
Mail list logo
