I hereby dub this THE BUG (at least for now)
Adam Young
ayoung at redhat.com
Sat Mar 27 02:13:29 UTC 2010
The inconsistancy with the consumed field has strechedinto its third
day, and is going to pass over the weekend. Not something that makes me
happy. Here's what I've learned:
We are property committing the transactions. I see the commit call
in the Java code, and the value in the database
There are multiple objects of Class Pool that are used to hold the
Pool with ID 4 (prodid='virtualization_host') with different values for
consumed. While there should be multiple instances, there should be one
per session, created after the start of the http request that access
them. This request should fetch the value from the Databse...or some
more complicated cache consistancy protocol should take effect, but I
have yet to see any indication of that.
I see two updates of the cp_pool table, which map to the bump and
dock calls. But in between, there is no corresponding select, which
means that if the value is written to the databse, it is never read out
again.
The object used for the bump call is not the same as the object used
for the dock call.
I asked mazz about it. Here's his explanation of how things work in
rhq, which shouldn't be that different from what we are doing:
"I'm used to being in the EJB3 world - whenever a new tx is started in
an EJB3 method, that starts with an empty cache. As you "do things" with
hib/jpa, the cache is populated. If you entityManager.clear(), you clear
the cache - otherwise, the cache maintains its state until that tx is
committed (i.e. you leave the tx context by say returning from the EJB3
method) you can layer another level of cache on top of this (like
ehcache) for cluster caching and things, and I don't know how this
works with extended persistence contexts in JPA. that's where a session
extends past tx boundaries"
I think we were lucky to catch this early, as it could well have burnt
us post production.
One hypothesis is that the dock call is using a session that started
before the bump call, and so has a version of the pool that pre-exists
the bump call. WHy that would be, I don't know.
I put a breakpoint on the constructors for Pool. Sometimes the no-arg
constructor gets called between bump and dock, but not always.
Happy Passover.
More information about the candlepin
mailing list