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