Spurious UPDATE commands

RT Developers
1

Hello All,

While testing some performance tests I came across a few deadlocks. Our
systems are Oracle XE with rt-3.6.4 and I noticed that there are a few
commands like these:
UPDATE attachments
SET headers = :p1
WHERE ID = :p2
I can’t find where they are generated and I’m wondering why they are
there because why update the headers of an attachment when displaying a
ticket or the history because that is when they are generated. The
deadlock occurs because the next request is going to another apache
proces+connection to the database where it will also try to update the
same record --> deadlock.
There are 3 more update commands in our production:
UPDATE cachedgroupmembers
SET via = :p1
WHERE ID = :p2
UPDATE principals
SET objectid = :p1
WHERE ID = :p2
UPDATE tickets
SET lastupdated = :p1
WHERE ID = :p2

They all can be explained as needed by the system, mainly housekeeping.

Greetings,

Joop

2

Joop wrote:

Hello All,

While testing some performance tests I came across a few deadlocks. Our
systems are Oracle XE with rt-3.6.4 and I noticed that there are a few
commands like these:
Deadlock problem is solved, my own fault.
Don’t play with DBI settings without removing them when not needed.

UPDATE attachments
SET headers = :p1
WHERE ID = :p2
Question is still valid, why update a field when displaying a ticket or
history?

Greetings,

Joop

3

UPDATE attachments
SET headers = :p1
WHERE ID = :p2
Question is still valid, why update a field when displaying a
ticket or history?

sub ContentLength in Attachment_Overlay.pm. We sometimes need to get
the decoded length of attachments. It’s not always in the message
header, where it should be. This writes it in there if it’s not.

PGP.sig (186 Bytes)