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

[Kenneth Marshall]

On Fri, Jun 25, 2010 at 08:21:55AM -0500, Hussam Dawood wrote:
> Hello,
>
> 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 are trying to track down where this issue is coming from. So far one 
> thing we have figured out is that the more random the apache thread that is 
> serving the 'GET' request is, the better our chances of getting fresh data 
> (i.e. the newly set Owner). This is a little problematic since we have 
> noticed that some user agents (say Firefox or Chrome) keep their 
> connections open to the server (assuming this is due to KeepAlive) and get 
> served by the same apache process for quite some time. This causes them to 
> keep getting stale data for some time after the SetOwner() process has 
> taken place.
>
> 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:
>
> Set($UseTransactionBatch, 1); - both 0 and 1 - thinking that batching 
> transactions was causing SetOwner() to take not take effect immediately
>
> Set($WebFlushDbCacheEveryRequest, 0); - couldn't find much documentation on 
> this but thought it might be relevant to our endeavors.
>
> I am eager to find out if someone has run into this issue before or has 
> suggestions for things we can try to eliminate this issue.
>
> Thank you,
> 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
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