<p>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?<br>
</p>
<div class="gmail_quote">On Nov 17, 2011 10:27 AM, "Galder Zamarreño" <<a href="mailto:galder@redhat.com">galder@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's on my TODO list to create a wiki on it: <a href="https://issues.jboss.org/browse/ISPN-1120" target="_blank">https://issues.jboss.org/browse/ISPN-1120</a><br>
<br>
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.<br>
<br>
<a href="http://www.slideshare.net/galderz/infinispan-for-dummies" target="_blank">http://www.slideshare.net/galderz/infinispan-for-dummies</a> - slide 12 for characteristics of a PFER as opposed to a Put<br>
<br>
On Nov 17, 2011, at 9:36 AM, Sanne Grinovero wrote:<br>
<br>
> Hi Galder,<br>
> could you explain some details of the use case / requirements of<br>
> putForExternalRead ? I'm assuming you're talking about the Hibernate<br>
> 2nd level cache, but I don't know exactly how that is designed, do we<br>
> have some documentation about it?<br>
><br>
> Cheers,<br>
> Sanne<br>
><br>
> On 17 November 2011 09:30, Galder Zamarreño <<a href="mailto:galder.zamarreno@redhat.com">galder.zamarreno@redhat.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> Forcing caches to be either transactional or non transactional caches causes some issues with operations such as putForExternalRead with default configuration options.<br>
>><br>
>> Assuming we have a transactional cache, if autoCommit is on (default), putForExternalRead will:<br>
>> 1. Suspend the ongoing transaction<br>
>> 2. Will create a brand new transaction due to implicit transaction creation logic in auto commit.<br>
>><br>
>> This is not good.<br>
>><br>
>> 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:<br>
>> The whole point of calling PFER is to suspend on-going transactions, so it kinda implies that transactions are managed externally already.<br>
>><br>
>> If we don't disable autoCommit globally, there's a few things that we should consider doing:<br>
>> 1. Print a WARN if PFER is called and autoCommit is on?<br>
>> 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.<br>
>><br>
>> WDYT?<br>
>> --<br>
>> Galder Zamarreño<br>
>> Sr. Software Engineer<br>
>> Infinispan, JBoss Cache<br>
>><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
--<br>
Galder Zamarreño<br>
Sr. Software Engineer<br>
Infinispan, JBoss Cache<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div>