[infinispan-dev] PutForExternalRead and autoCommit
Manik Surtani
manik at jboss.org
Mon Nov 21 17:24:56 EST 2011
On 21 Nov 2011, at 09:34, Galder Zamarreño wrote:
>
> On Nov 17, 2011, at 4:39 PM, Slorg1 wrote:
>
>> Hi all,
>>
>> See comment below,
>>
>> On Thu, Nov 17, 2011 at 10:20, Galder Zamarreño <galder at redhat.com> wrote:
>>>
>>> On Nov 17, 2011, at 2:54 PM, Manik Surtani wrote:
>>>
>>>> On 17 Nov 2011, at 09:30, Galder Zamarreño wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Forcing caches to be either transactional or non transactional caches causes some issues with operations such as putForExternalRead with default configuration options.
>>>>>
>>>>> Assuming we have a transactional cache, if autoCommit is on (default), putForExternalRead will:
>>>>> 1. Suspend the ongoing transaction
>>>>> 2. Will create a brand new transaction due to implicit transaction creation logic in auto commit.
>>>>>
>>>>> This is not good.
>>>>
>>>> What's not good about this? 1 is by design and is correct behaviour. 2 should not affect anything, since the new tx is completed at the end of the PFER invocation.
>>>
>>> 2 does not affect anything but seems wasteful to me. Why start a transaction when I don't need one?
>>
>> I do not understand the need for #1 to happen given that a running
>> transaction already exist. In the case of a replicated cache, that
>> transaction exists remotely on all other nodes.
>> Thus why not apply the put under the same scope ?
>
> It's an optimisation since we're reading from the external source of data. This optimisation avoids locking issues as a result of trying to read the same piece of data into the cache when executed concurrently in different nodes.
>
> Read the putForExternal read javadoc to find out more.
It's not so much locking issues as it is that the pFER operation cannot and will not cause the database operation to fail/rollback. And this is important. Since in this use case, Infinispan is used as a throwaway cache. If we can't cache a DB read for some reason, we shouldn't fail the whole transaction. And hence the suspending/starting a new transaction for the pFER operation.
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111121/e0796bfb/attachment.html
More information about the infinispan-dev
mailing list