[rt-users] Understanding behavior of Ticket->SetOwner()

[Hussam Dawood]

On 07/02/2010 01:23 PM, Kenneth Marshall wrote:
> On Fri, Jul 02, 2010 at 01:04:22PM -0500, Hussam Dawood wrote:
>> On 06/25/2010 08:31 AM, Kenneth Marshall wrote:
>>> On Fri, Jun 25, 2010 at 08:21:55AM -0500, Hussam Dawood wrote:
>>> I am not certain why a work-flow would first set the owner of a ticket
>>> and then immediately try to get the owner using a query even though
>>> the owner change completed without an error. I think you are running
>>> into a whole host of caching effects that keep the whole application
>>
>> You were right. Caching did turn out to be the problem. We tried
>> SearchBuilder 1.56 just out of curiosity and that did not help. Finally,
>> with the help of a colleague, we went back to modifying _CacheConfig() and
>> tried setting the cache_for_sec key in
>> /usr/share/request-tracker3.6/lib/RT/Record.pm to:
>>
>>    cache_for_sec =>  -1
>>
>> apparently 0 and -1 have a totally different meaning. I could not find any
>> documentation on this and we are continuously looking to see what the
>> difference is. However, testing for at least a couple of hours constantly
>> taking/untaking tickets and reading the Owner always returns the correct
>> value.
>>
>> Hopefully this saves someone else the trouble as well. One previous post in
>> the RT-Users mailing list that gave us a few hints follows:
>>
>>    http://www.gossamer-threads.com/lists/rt/users/37978
>>
>> We experimented a bit and decided to not override the Record.pm file
>> globally (so as to leave RT's code pristine), and instead chose to override
>> the _CacheConfig subroutine in our startup.pl file for mod_perl:
>>
>>    BEGIN {
>>      use RT;
>>      use RT::Ticket;
>>
>>      *RT::Ticket::_CacheConfig = sub {
>>          {
>>              cache_p =>  1,
>>              cache_for_sec =>  -1
>>          }
>>      };
>>
>>    }
>>
>>> from being totally DB limited. Caching is a huge win in most cases and
>>> user education may be a better way of handling this issue than turning
>>> off or disabling the caching. Maybe someone else will have some other
>>> ideas.
>>>
>>> Cheers,
>>> Ken
>>
>> H. Dawood
>
> Thank you for the follow-up. I took a quick look at the Cacheable
> module in SearchBuilder. I had a function called FlushCache() with
> the obvious definition. Maybe you could call it after setting the
> Owner and avoid the need for disabling the caching completely.
>
> Cheers,
> Ken

I just tried the above on the $ticket object responsible for SetOwner(), 
however, within just 2 tries I was able to replicate the issue.

I checked to make sure I'm calling FlushCache() on the right object as 
well. It seems like RT::Ticket is extending RT::Record which extends 
DBIx::SearchBuilder::Record::Cacheable so I am assuming what I did was 
correct, however if not, would you kindly correct me please?

The $ticket object is instantiated as:
   my $current_user = RT::CurrentUser->new();
   $current_user->LoadByName('ticket_user');
   my $ticket = new RT::Ticket( $current_user );

H. Dawood