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
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
