[infinispan-dev] Event handling behaviour

[Galder Zamarreño]

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.

Finallt, to give you an idea of the kind of visibility test you'd need, check CacheListenerVisibilityTest which was implemented for non-transactional caches.

Cheers,

> 
> Any other suggestion?
> 
> Cheers,
> Pedro
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org