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