[infinispan-dev] PutForExternalRead and autoCommit

[Galder Zamarreño]

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 at 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache