I hereby dub this THE BUG (at least for now)

Adam Young ayoung at redhat.com
Mon Mar 29 13:01:34 UTC 2010


On 03/29/2010 08:34 AM, Bryan Kearney wrote:
> On 03/29/2010 08:28 AM, Jesus M. Rodriguez wrote:
>    
>> On Mon, Mar 29, 2010 at 8:25 AM, Bryan Kearney<bkearney at redhat.com>   wrote:
>>      
>>> On 03/26/2010 10:13 PM, Adam Young wrote:
>>>        
>>>> 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.
>>>>          
>>> Couple of questions:
>>>
>>> 1) Does it make sense to look at an EJB container to avoid this?
>>>        
>> please no, not to bring up old tech, but we managed to do just
>> fine without an EJB container on Spacewalk and the transactions
>> work just fine.
>>      
> I have to ask! Keep in mind, EJB3 is much nicer than EJB2. In fact, It
> would not look much different.
>    
I think we are at the point where switching technology will provide us 
easy fixes.
>    
>>      
>>> 2) Assuming 1 is No, can we wrap the entry / exit points to create a new
>>> session / clear the session each time?
>>>        
>> probably, I'd have to look at how we're doing it in candlepin. In the past
>> we let the first use of hibernate create the session, then we used a filter
>> to commit/rollback the transactions and end the session per request.
>>
>> So it seems to me we can do a similar thing in candlepin.
>>
>>      
> So.. I am assuming here it would be one session per request.
>    
The thing is, we seem to be doing that already.  I'd love to get a 
second set of eyes on this, to make sure I am not misreading the data.


> -- bk
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>    




More information about the candlepin mailing list