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

[Hussam Dawood]

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