Hi all,
Last few days I’ve been having fun fixing [1] and the solution I’ve got to has
some links to [2].
The problem is that when getCacheEntry() is called, the entry returned could be
partially correct. Up until now, we’d send back a cache entry back to the
client that the user could not
On Jun 24, 2014, at 15:27, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
Last few days I’ve been having fun fixing [1] and the solution I’ve got to
has some links to [2].
The problem is that when getCacheEntry() is called, the entry returned could
be partially correct. Up until
On 24 Jun 2014, at 16:51, Mircea Markus mmar...@redhat.com wrote:
On Jun 24, 2014, at 15:27, Galder Zamarreño gal...@redhat.com wrote:
Hi all,
Last few days I’ve been having fun fixing [1] and the solution I’ve got to
has some links to [2].
The problem is that when getCacheEntry()
On 06/24/2014 05:11 PM, Mircea Markus wrote:
On Jun 24, 2014, at 16:50, Galder Zamarreño gal...@redhat.com wrote:
On 24 Jun 2014, at 16:51, Mircea Markus mmar...@redhat.com wrote:
On Jun 24, 2014, at 15:27, Galder Zamarreño gal...@redhat.com wrote:
To fix this, I’ve been working with
I must admit this seems a bit heavy handed to have to enable
transactions, when are using them solely for the purpose of having
implicit transactions.
Can we not instead just tweak the NonTransactionalLockingInterceptor
to obey the FORCE_WRITE_LOCK, so it would guarantee a consistent value
in the
