[infinispan-dev] Event handling behaviour

[Radim Vansa]

On 10/17/2013 09:36 AM, Galder Zamarreño wrote:
> On Oct 11, 2013, at 11:30 AM, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>> Hi guys.
>>
>> Re: https://issues.jboss.org/browse/ISPN-2090
>>
>> Summary: in tx caches, when @listener(sync = true), the callback is done
>> by the same thread as the transaction. However, most of the events may
>> not cause any problem, some of them are trigger when the transaction is
>> in the state that cannot attach more commands.
>>
>> So, I want to discuss here what would be the correct behaviour/logic for
>> the callback (note this only affects tx caches) assuming that the
>> callback invokes some operation (get/put/etc.) over the cache.
>>
>> IMO, all the synchronous events should suspend the transaction. This
>> way, we ensure that the operation is not attached to the transaction,
>> the callback has the same behaviour if sync=true and sync=false and also
>> with the events triggered in remote nodes (you will never read any
>> non-committed data from a remote transaction neither attach the operation).
> ^ I think it makes sense, but this would break code that's based around the current assumptions, and given how late we are in the 6.0 release, I would not add this right now, and when added it needs to be properly documented to indicate the differences.
>
>> Mircea suggestion is the following:
> <- missing something here?
>
>> I think the correct logic should be:
>>
>> * if isPre() then the value should not be seen when reading the cache
>> * if !isPre() then value should be seen. Not totally sure, but the
>> transaction as return by TransactionManager.getTransaction should not be
>> visible (i.e. suspend it before notifying the listener), as this would
>> result in different behavior on local/remote nodes that get notified.
> ^ I'm not sure how you can achieve for data to be seen when !is.Pre(), assuming you mean data that's accessible via the cache interface and not data that comes as part of the event. I'd say that both isPre and !isPre should not allow on-going transaction data when accessing via the cache. Of course, event parameters should carry the data that the user might need.
Carrying the data in parameter might not be enough if you allow the 
event listener to do writes, IMO. Let's have A=1, B=1 in cache and 
application constraint that A >= B. Let's set A to 2 - that would fire 
an event in which you would like to set B to 2, and B's event listener 
would like to know value of A - getting A = 1 will break the constraint. 
And there's no way to get A's value besides reading it directly from cache.


Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA