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