On 14 Dec 2011, at 13:55, Galder Zamarreño wrote:
>>>
>>> Yeah it's pointless to use locks if you have a single operation, but I
>>> might want to do more operations in a single transaction.. actually
>>> what's the point of using a transaction if I have only one operation?
>> WIthout transactio
> I think they are really counter intuitive and very expensive,
I can't see how these can be more expensive than explicitly started
transactions?
> and
> arguably wrong in a pure transactional context like mine. I said
> 'arguably' because I do not want to restart the discussion about it, I
> just
On 13 Dec 2011, at 19:08, Galder Zamarreño 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 failure
>>
On 14 Dec 2011, at 15:55, Galder Zamarreño wrote:
>
> On Dec 14, 2011, at 2:45 PM, Mircea Markus wrote:
>
>>
>> On 13 Dec 2011, at 16:00, Sanne Grinovero wrote:
>>
>>> On 13 December 2011 13:48, Galder Zamarreño wrote:
On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
On Dec 14, 2011, at 2:45 PM, Mircea Markus wrote:
>
> On 13 Dec 2011, at 16:00, Sanne Grinovero wrote:
>
>> On 13 December 2011 13:48, Galder Zamarreño wrote:
>>>
>>> On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
>>>
Why would you avoid FORCE_WRITE_LOCK ?
>>>
>>> Does the followi
On 13 Dec 2011, at 17:04, 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
On 13 Dec 2011, at 16:00, Sanne Grinovero wrote:
> On 13 December 2011 13:48, Galder Zamarreño 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()
>> cache.withFlags(FORCE_WRITE_L
On 13 Dec 2011, at 15:49, Galder Zamarreño 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()
> cache.withFlags(FORCE_WRITE_LOCK).get(…)
> tx.commit()
>
> It doesn't in my view. You
On 13 Dec 2011, at 14:10, Galder Zamarreño wrote:
> 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
Hi,
On Tue, Dec 13, 2011 at 12:08, Galder Zamarreño 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 failu
; boolean result = cache.withFlags(FAIL_SILENT).lock(k);
>>> // Something interesting..
>>> tx.commit();
>>>
>>> ...Same reason. I have a pool of keys and if one fails, I go to the next
>>> one. Again, keeps me from needing to acquire a bunch of explicit locks.
&
f Of Galder
> Zamarreño
> Sent: Tuesday, December 13, 2011 8:49 AM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Some flags are incompatible with implicit
> transactions
>
>
> On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
>
>> Why would you avoid
On Dec 13, 2011, at 3:00 PM, Sanne Grinovero wrote:
> On 13 December 2011 13:48, Galder Zamarreño 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()
>> cache.withFlags(FORCE_WRIT
Hi,
On Tue, Dec 13, 2011 at 10:45, Sanne Grinovero wrote:
> On 13 December 2011 15:04, 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
>>
On 13 December 2011 15:04, 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
>
; [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Sanne Grinovero
> Sent: Tuesday, December 13, 2011 9:24 AM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Some flags are incompatible with implicit
> transactions
>
> Right, it's also very useful to acquire locks o
esday, December 13, 2011 9:24 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Some flags are incompatible with implicit
transactions
Right, it's also very useful to acquire locks on aggregates or groups
by locking a representative known key for the group instead of on each
element; v
] On Behalf Of Galder
> Zamarreño
> Sent: Tuesday, December 13, 2011 8:49 AM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Some flags are incompatible with implicit
> transactions
>
>
> On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
>
>> Why would yo
riginal Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Galder
Zamarreño
Sent: Tuesday, December 13, 2011 8:49 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Some flags are incompatible with implicit
transactions
On Dec
On 13 December 2011 13:48, Galder Zamarreño 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()
> cache.withFlags(FORCE_WRITE_LOCK).get(…)
> tx.commit()
Yeah it's pointless to use locks if you
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 knowledg
Why would you avoid FORCE_WRITE_LOCK ? Will I still be able to use an
explicit cache.lock() operation? Acquiring a pessimistic lock might be
an important functionality in some use cases.
About FAIL_SILENT.. I'm not sure about the use case, but I would
expect it to just avoid logging errors and to
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 FAIL_
23 matches
Mail list logo
