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

[Kenneth Marshall]

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:
>>> We are running a mod_perl2 (2.0.4) REST application (using apache 2.2.9)
>>> that handles various ticket operations for us using RT (rt-3.6.7 backed 
>>> by
>>> MySQL 5.0.51a). These operations include creating tickets, setting 
>>> owners,
>>> setting states, changing queues etc. The front-end to all of this is a
>>> simple web-form that allows for the above actions to take place as well 
>>> as
>>> injecting some custom fields when creating the tickets.
>>>
>>> We are having an issue with the SetOwner() portion of the ticket object,
>>> where sometimes if someone changes the ticket owner to someone else or
>>> 'Nobody' and immediately queries the ticket again, the old owner is
>>> returned.  We are sure the SetOwner() action is not failing since 
>>> querying
>>> the database immediately after the action shows the new OwnerId and no
>>> error code is returned from SetOwner() as well.
>>>
>>> We thought at first that our SearchBuilder package (SearchBuilder 1.54) 
>>> may
>>> be the culprit here, however, setting the 'cache_for_sec' key under sub
>>> _CacheConfig {} from the default '5' seconds to '0' or '1' did not prove
>>> useful. We also tried the following settings under RT_SiteConfig.pm which
>>> did not resolve our issue either:
>>>
>>> H. Dawood
>>
>> 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