5:19 a.m.
The intention is the following:
Imagine N threads trying to load the same piece of data from a database into the cache.
With a normal put, they'd all be fighting against each other to get the locks for no
reason.
The idea here is that we want to store something in the cache which we know is not there,
but someone, might concurrently try to retrieve it from the db too, so let's one of
them do it and the rest, in further interactions, will be able to use the cached value
directly.
This is different to trying to update an entity. If multiple threads are trying to modify
an entity, these need to go through the normal lock procedure.
On Nov 17, 2011, at 11:45 AM, Sanne Grinovero wrote:
Yes I know the javadocs of the flags, it's the cache integration
with hibernate's state which uses a transactional synch which puzzles me: it seems we
want the change to be transactional, and at the same time apply flags which express
"we don't care for consistency". What is the intention?
On Nov 17, 2011 10:27 AM, "Galder Zamarreño" <galder(a)redhat.com> wrote:
It's on my TODO list to create a wiki on it:
https://issues.jboss.org/browse/ISPN-1120
The javadoc should be clear enough but basically, it's a put operation geared towards
best-effort, when you're trying to put somewhere read from an external source.
http://www.slideshare.net/galderz/infinispan-for-dummies - slide 12 for characteristics
of a PFER as opposed to a Put
On Nov 17, 2011, at 9:36 AM, Sanne Grinovero wrote:
> Hi Galder,
> could you explain some details of the use case / requirements of
> putForExternalRead ? I'm assuming you're talking about the Hibernate
> 2nd level cache, but I don't know exactly how that is designed, do we
> have some documentation about it?
>
> Cheers,
> Sanne
>
> On 17 November 2011 09:30, Galder Zamarreño <galder.zamarreno(a)redhat.com>
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.
>>
>> I don't think we can just disable autoCommit globally if someone calls
putForExternalRead because there might other operations not called within a transaction,
but there's a point to be made here:
>> The whole point of calling PFER is to suspend on-going transactions, so it kinda
implies that transactions are managed externally already.
>>
>> If we don't disable autoCommit globally, there's a few things that we
should consider doing:
>> 1. Print a WARN if PFER is called and autoCommit is on?
>> 2. Apart from the message, some kind of way for putForExternalRead to instruct
the implicit transaction logic to avoid creating a new transaction in this case.
>>
>> WDYT?
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache