[infinispan-dev] PutForExternalRead and autoCommit

[Sanne Grinovero]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111117/648eb33a/attachment.html