Mysql DB engine ndbdcluster

Reinhold_Pescoller · December 13, 2016, 9:28am

Hi,

Is there some possibilty to change the default db engine from innodb to
ndbdcluster in rt4?

thanks

chmrr · December 13, 2016, 10:26am

Is there some possibilty to change the default db engine from innodb to
ndbdcluster in rt4?

RT assumes REPEATABLE READ isolation; you may encounter subtle and
difficult to diagnose bugs under READ COMMITTED isolation, which is all
that NDB supports. Performance of joins is generally not great under
NDB, and RT assumes that joins do not incur a significant cost penalty.

In short, you might be able to get it to run simply by adjusting the
table types, but I only expect it to get you into trouble down the road.

Alex

chmrr · December 14, 2016, 5:05am

Thanks for your informations.

I tried to do so but rt give me an error that innodb is required and
that I should upgrade my tables.
Have I to change this direct in the code?

lib/RT/Handle.pm:

github.com

bestpractical/rt/blob/095caac2a4b4fc7baba0d7878a79f8b486579854/lib/RT/Handle.pm#L291


      
              return (0, "RT requires that MySQL be compiled with InnoDB table support.\n".
                  "See <http://dev.mysql.com/doc/mysql/en/innodb-storage-engine.html>\n".
                  "and check that there are no 'skip-innodb' lines in your my.cnf.");
          } elsif ( $innodb eq "disabled" ) {
              return (0, "RT requires that MySQL InnoDB table support be enabled.\n".
                  "Remove the 'skip-innodb' or 'innodb = OFF' line from your my.cnf file, restart MySQL, and try again.\n");
          }
          
          if ( $state eq 'post' ) {
              my $show_table = sub { $dbh->selectrow_arrayref("SHOW CREATE TABLE $_[0]")->[1] };
              unless ( $show_table->("Tickets") =~ /(?:ENGINE|TYPE)\s*=\s*InnoDB/i ) {
                  return (0, "RT requires that all its tables be of InnoDB type. Upgrade RT tables.");
              }
          
              unless ( $show_table->("Attachments") =~ /\bContent\b[^,]*BLOB/i ) {
                  return (0, "RT since version 3.8 has new schema for MySQL versions after 4.1.0\n"
                      ."Follow instructions in the UPGRADING.mysql file.");
              }
          }
          
          if ($state =~ /^(create|post)$/) {

I’ll reiterate that while RT may appear to work in trivial
conditions, you’re setting yourself up for a world of both poor
performance and nasty race condition bugs. You get to keep all of the
pieces when it bursts into flames in production – NDB is in no way a
supported, suggested, or sane backing engine for RT.

Alex

Mike_Diehl · December 14, 2016, 2:42pm

At the risk of picking a fight, I’d like to understand this a bit better.

As long as the database supports minimum functions, such as transactions,
joins, datatypes, etc., why should an application care about the underlying
storage engine?

Are you trying to imply that ndbcluster simply isn’t production-ready? If so,
then end of conversation.

Otherwise, what are some of the issues the OP will have to look forward to?

Thanks.

Mike.On Tuesday, December 13, 2016 09:05:11 PM Alex Vandiver wrote:

On Tue, 13 Dec 2016 12:25:37 +0100 Pescoller Reinhold reinhold@aiding.it wrote:

Thanks for your informations.

I tried to do so but rt give me an error that innodb is required and
that I should upgrade my tables.
Have I to change this direct in the code?

lib/RT/Handle.pm:
GitHub - bestpractical/rt at 095caac2a4b4fc7baba0d7878a79f8b486579854
79854/lib/RT/Handle.pm#L291

I’ll reiterate that while RT may appear to work in trivial
conditions, you’re setting yourself up for a world of both poor
performance and nasty race condition bugs. You get to keep all of the
pieces when it bursts into flames in production – NDB is in no way a
supported, suggested, or sane backing engine for RT.

Alex

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training * Los Angeles - January 9-11 2017

Mike Diehl
Diehlnet Communications, LLC.
Sales: (800) 254-6105
Voice: (505) 903-5700
Fax: (505) 903-5701

chmrr · December 15, 2016, 8:07am

At the risk of picking a fight, I’d like to understand this a bit better.

Happy to explain more – and my instinct may have been wrong on one
count; see below.

As long as the database supports minimum functions, such as transactions,
joins, datatypes, etc., why should an application care about the underlying
storage engine?

Because distributed databases have different properties around
atomicity and data locality than single-host databases. Applications
running atop such databases need to be built to accommodate these
correctness and performance properties.

The biggest issue is that of transaction isolation[1] – not all
transactions are equal. RT assumes that a database transaction gives it
“repeatable read” isolation from other transactions. This isolation
level, the default for InnoDB tables[2], means that essentially, upon
the first read, a snapshot of the state of the database is taken, and
it provides strong guarantees that regardless how long the transaction
is open, all queries within it will return consistent data[3].

I believe it likely (though I cannot prove, offhand) that RT assumes
repeatable read isolation semantics – and NDB only offers “read
committed” isolation, which admits the possibility of different
results for the same query run twice within the same transaction.

However, upon writing this, it occurs to me that Postgres’ default
isolation level is also “read committed.”[4] Thus any possible race
conditions that might show up under NDB are also possible under
Postgres. I’d need to do some close analysis to determine if this
means that Postgres is open to data corruption, or if both are safe
because the queries RT runs do not care about repeatable-read
semantics.

So NDB may actually be fine on this front.

The other property concerns data locality, and is purely a performance
constraint. NDB stores data across a cluster of data notes,
optionally with replication, which are queried by other hosts that
serve as SQL nodes[5]. This means that joining data across tables
cannot be done in-memory, but instead may incur network-level
latencies to match up the data between data nodes – meaning poor
query performance.

MySQL Cluster 7.2 (equivalent to MySQL 5.5) does provide some tricks to
prevent this performance hit[6], but it’s not clear that those
optimizations will be able to be applied to RT’s queries, as not all of
the column types match between tables. It also doesn’t get you all
of the way to InnoDB join performance. Finally, the tables may also
need explicit hinting in order to partition the data to give any sort of
locality across the hosts.

On the other hand, if you’re deploying an NDB cluster, you may already
have the MySQL DBAs on-hand to attend to those. I’ve never heard of
an NDB deploy, discovering the correct partitioning scheme would be
all uncharted territory.

NDB clusters also don’t support FULLTEXT indexes[7], though that’s
clearly only an optional feature for RT.

Pescoller, consider me curious to hear back if you actually deploy RT
against and NDB cluster in production, and the performance
characteristics you see compared to single-host InnoDB.

Alex

[1] Isolation (database systems) - Wikipedia
[2] https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html
[3] Repeatable read nominally opens up the possibility of “phantom
reads” where range queries can return inconsistent data from one query
to another; however, InnoDB uses some clever locking tricks to prevent
them.
[4] PostgreSQL: Documentation: 9.1: Transaction Isolation
[5] http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-overview.html
[6] http://mysqlhighavailability.com/70x-faster-joins-with-aql-in-mysql-cluster-7-2/
[7] https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-limitations-syntax.html

Torsten_Brumm · December 15, 2016, 8:19am

Hi Reinhold,
whats the goal of doing this? Not sure with ndbcluster, but we do it with percona cluster and this does very well.

Torsten-----Ursprüngliche Nachricht-----
Von: rt-users [mailto:rt-users-bounces@lists.bestpractical.com] Im Auftrag von Reinhold Pescoller
Gesendet: Dienstag, 13. Dezember 2016 10:29
An: rt-users
Betreff: [rt-users] mysql DB engine ndbdcluster

Hi,

Is there some possibilty to change the default db engine from innodb to ndbdcluster in rt4?

thanks

RT 4.4 and RTIR training sessions, and a new workshop day! Training — Best Practical Solutions

Los Angeles - January 9-11 2017

Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), Martin Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Mustafa Sener.

Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteurbedingungen 2016 (ADSp 2016). Die ADSp 2016 beschränken in Ziffer 23 die gesetzliche Haftung für Güterschäden in Höhe von 8,33 SZR/kg je Schadenfall bzw. je Schadenereignis auf 1 Million bzw. 2 Millionen Euro oder 2 SZR/kg, je nachdem, welcher Betrag höher ist, und bei multimodalen Transporten unter Einschluss einer Seebeförderung generell auf 2 SZR/kg. Den vollständigen Text der ADSp 2016 übersenden wir Ihnen gerne auf Anfrage und können Sie auch unter http://www.kuehne-nagel.com einsehen.

Vaclav_Ovsik · December 21, 2016, 5:38pm

Hi,On Thu, Dec 15, 2016 at 12:07:54AM -0800, Alex Vandiver wrote:

…
However, upon writing this, it occurs to me that Postgres’ default
isolation level is also “read committed.”[4] Thus any possible race
conditions that might show up under NDB are also possible under
Postgres. I’d need to do some close analysis to determine if this
means that Postgres is open to data corruption, or if both are safe
because the queries RT runs do not care about repeatable-read
semantics.
…

I afraid you are right, Postgreses default isolation level is ‘read
committed’. I filled bug-report two months ago.
https://issues.bestpractical.com/Ticket/Display.html?id=32381

I’m running PostgreSQL & RT on Debian Jessie, that is Pg 9.4 & RT 4.4.1.
I did only a basic PostgreSQL performance tuning, but didn’t change the
default transaction isolation level. I can’t find anything about needed
transaction isolation level through RT documentation. I read this fact,
that RT assumes “repeatable-read” isolation level for the first time.

Nevertheless we are hit only by the problem during Comment/Correspond
together with ticket owner change only (I hope).

I did some testing right now on testing RT instance:

default “committed read” isolation level
- I’m getting from time to time:
2016-12-21 11:33:38 CET [22545-1] rt_rt@rt ERROR: deadlock detected
2016-12-21 11:33:38 CET [22545-2] rt_rt@rt DETAIL: Process 22545 waits for ShareLock on transaction 8351856; blocked by process 22539.
Process 22539 waits for ShareLock on transaction 8351857; blocked by process 22545.
Process 22545: UPDATE Tickets SET Owner=$1 WHERE id=$2
Process 22539: INSERT INTO GroupMembers (LastUpdatedBy, LastUpdated, GroupId, MemberId, Creator, Created) VALUES ($1, $2, $3, $4, $5, $6)
2016-12-21 11:33:38 CET [22545-3] rt_rt@rt HINT: See server log for query details.
2016-12-21 11:33:38 CET [22545-4] rt_rt@rt CONTEXT: while updating tuple (4336,144) in relation “tickets”
2016-12-21 11:33:38 CET [22545-5] rt_rt@rt STATEMENT: UPDATE Tickets SET Owner=$1 WHERE id=$2
default_transaction_isolation = ‘repeatable read’
- I’m getting the following errors, but on the application level
  things seems to be normal.
2016-12-21 17:20:41 CET [25923-1] rt_rt@rt ERROR: could not serialize access due to concurrent update
2016-12-21 17:20:41 CET [25923-2] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1 FOR UPDATE
2016-12-21 17:20:41 CET [25923-3] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-4] rt_rt@rt STATEMENT: INSERT INTO Transactions (OldReference, ObjectType, Data, Field, ObjectId, Type, NewValue, ReferenceType, OldValue, Created, NewReference, Creator) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12)
2016-12-21 17:20:41 CET [25923-5] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-6] rt_rt@rt STATEMENT: SELECT * FROM Transactions WHERE id = $1
2016-12-21 17:20:41 CET [25923-7] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-8] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-21 17:20:41 CET [25923-9] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-10] rt_rt@rt STATEMENT: SELECT * FROM Transactions WHERE id = $1
2016-12-21 17:20:41 CET [25923-11] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-12] rt_rt@rt STATEMENT: SELECT main.* FROM Scrips main JOIN ObjectScrips ObjectScrips_1 ON ( ObjectScrips_1.Scrip = main.id ) JOIN ScripConditions ScripConditions_2 ON ( ScripConditions_2.id = main.ScripCondition ) WHERE (ObjectScrips_1.ObjectId = ‘0’) AND (ObjectScrips_1.Stage = ‘TransactionCreate’) AND (ScripConditions_2.ApplicableTransTypes LIKE ‘%Comment%’ OR ScripConditions_2.ApplicableTransTypes LIKE ‘%Any%’) AND (main.Disabled = ‘0’) GROUP BY main.id ORDER BY MIN(ObjectScrips_1.SortOrder) ASC
2016-12-21 17:20:41 CET [25923-13] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-14] rt_rt@rt STATEMENT: SELECT COUNT(DISTINCT main.id) FROM Scrips main JOIN ObjectScrips ObjectScrips_1 ON ( ObjectScrips_1.Scrip = main.id ) JOIN ScripConditions ScripConditions_2 ON ( ScripConditions_2.id = main.ScripCondition ) WHERE (ObjectScrips_1.ObjectId = ‘0’) AND (ObjectScrips_1.Stage = ‘TransactionCreate’) AND (ScripConditions_2.ApplicableTransTypes LIKE ‘%Comment%’ OR ScripConditions_2.ApplicableTransTypes LIKE ‘%Any%’) AND (main.Disabled = ‘0’)
2016-12-21 17:20:41 CET [25923-15] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-16] rt_rt@rt STATEMENT: SELECT main.* FROM Scrips main JOIN ObjectScrips ObjectScrips_1 ON ( ObjectScrips_1.Scrip = main.id ) JOIN ScripConditions ScripConditions_2 ON ( ScripConditions_2.id = main.ScripCondition ) WHERE (ObjectScrips_1.ObjectId = ‘0’) AND (ObjectScrips_1.Stage = ‘TransactionCreate’) AND (ScripConditions_2.ApplicableTransTypes LIKE ‘%Comment%’ OR ScripConditions_2.ApplicableTransTypes LIKE ‘%Any%’) AND (main.Disabled = ‘0’) GROUP BY main.id ORDER BY MIN(ObjectScrips_1.SortOrder) ASC
2016-12-21 17:20:41 CET [25923-17] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-18] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-21 17:20:41 CET [25923-19] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-20] rt_rt@rt STATEMENT: SELECT * FROM Transactions WHERE id = $1
2016-12-21 17:20:41 CET [25923-21] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-22] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-21 17:20:41 CET [25923-23] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-24] rt_rt@rt STATEMENT: UPDATE Tickets SET LastUpdated=$1 WHERE id=$2
2016-12-21 17:20:41 CET [25923-25] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-26] rt_rt@rt STATEMENT: UPDATE Tickets SET LastUpdated=$1 WHERE id=$2
2016-12-21 17:20:41 CET [25923-27] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-28] rt_rt@rt STATEMENT: UPDATE Tickets SET LastUpdated=$1 WHERE id=$2
2016-12-21 17:20:41 CET [25923-29] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-30] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-21 17:20:41 CET [25923-31] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-32] rt_rt@rt STATEMENT: SELECT * FROM Users WHERE id = $1
2016-12-21 17:20:41 CET [25923-33] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-34] rt_rt@rt STATEMENT: SELECT * FROM Users WHERE id = $1
2016-12-21 17:20:41 CET [25923-35] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-21 17:20:41 CET [25923-36] rt_rt@rt STATEMENT: SELECT * FROM Users WHERE id = $1
default_transaction_isolation = ‘serializable’
- I tried the action many times, but Pg is silent - nothing appears
  in its log file and everything seems normal.

Is there somebody with RT 4.4.1 (versions 4.2.x not suffers by this)
and PostgreSQL with similar symptoms?

The problem occurs probably only when we did action Comment or
Correspond and change the ticket owner in the one transaction.

Is it safe for me to change the default_transaction_isolation
in /etc/postgresql/9.4/main/postgresql.conf to ‘repeatable read’ ?
I’m a bit confused by errors above, maybe the failed transaction was
restarted?

Regards
Zito

Vaclav_Ovsik · December 22, 2016, 1:03pm

…

default_transaction_isolation = ‘serializable’

I tried the action many times, but Pg is silent - nothing appears
in its log file and everything seems normal.

Sorry, this is not true. I did more thorough testing today. I did experiments
on one test ticket and as the history of ticket grows, the probability of the
bug increases. Now it is almost certain the problem will occurs.
Isolation level ‘serializable’ behaves like ‘repeatable read’. So the summary is:

‘commited read’: → deadlock, application outputs error:

Comments added
Could not change owner: Could not update column Owner: Owner could not be set to 102.

Postgres log:

2016-12-22 13:18:18 CET [26070-1] rt_rt@rt ERROR: deadlock detected
2016-12-22 13:18:18 CET [26070-2] rt_rt@rt DETAIL: Process 26070 waits for ShareLock on transaction 32889; blocked by process 26097.
Process 26097 waits for ShareLock on transaction 32890; blocked by process 26070.
Process 26070: UPDATE Tickets SET Owner=$1 WHERE id=$2
Process 26097: INSERT INTO GroupMembers (LastUpdatedBy, Creator, Created, GroupId, MemberId, LastUpdated) VALUES ($1, $2, $3, $4, $5, $6)
2016-12-22 13:18:18 CET [26070-3] rt_rt@rt HINT: See server log for query details.
2016-12-22 13:18:18 CET [26070-4] rt_rt@rt CONTEXT: while updating tuple (4509,284) in relation “tickets”
2016-12-22 13:18:18 CET [26070-5] rt_rt@rt STATEMENT: UPDATE Tickets SET Owner=$1 WHERE id=$2

‘repeatable read’
‘serializable’: → application output normal status:

Comments added
Owner changed from eva to zito

Postgres log:
2016-12-22 13:26:36 CET [31696-1] rt_rt@rt ERROR: could not serialize access due to concurrent update
2016-12-22 13:26:36 CET [31696-2] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1 FOR UPDATE
2016-12-22 13:26:36 CET [31696-3] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-4] rt_rt@rt STATEMENT: INSERT INTO Transactions (Type, Creator, ObjectId, NewValue, Field, Data, ObjectType, NewReference, ReferenceType, Created, OldReference, OldValue) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12)
2016-12-22 13:26:36 CET [31696-5] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-6] rt_rt@rt STATEMENT: SELECT * FROM Transactions WHERE id = $1
2016-12-22 13:26:36 CET [31696-7] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-8] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-22 13:26:36 CET [31696-9] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-10] rt_rt@rt STATEMENT: SELECT * FROM Transactions WHERE id = $1
2016-12-22 13:26:36 CET [31696-11] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-12] rt_rt@rt STATEMENT: SELECT main.* FROM Scrips main JOIN ObjectScrips ObjectScrips_1 ON ( ObjectScrips_1.Scrip = main.id ) JOIN ScripConditions ScripConditions_2 ON ( ScripConditions_2.id = main.ScripCondition ) WHERE (ObjectScrips_1.ObjectId = ‘0’) AND (ObjectScrips_1.Stage = ‘TransactionCreate’) AND (ScripConditions_2.ApplicableTransTypes LIKE ‘%Comment%’ OR ScripConditions_2.ApplicableTransTypes LIKE ‘%Any%’) AND (main.Disabled = ‘0’) GROUP BY main.id ORDER BY MIN(ObjectScrips_1.SortOrder) ASC
2016-12-22 13:26:36 CET [31696-13] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-14] rt_rt@rt STATEMENT: SELECT COUNT(DISTINCT main.id) FROM Scrips main JOIN ObjectScrips ObjectScrips_1 ON ( ObjectScrips_1.Scrip = main.id ) JOIN ScripConditions ScripConditions_2 ON ( ScripConditions_2.id = main.ScripCondition ) WHERE (ObjectScrips_1.ObjectId = ‘0’) AND (ObjectScrips_1.Stage = ‘TransactionCreate’) AND (ScripConditions_2.ApplicableTransTypes LIKE ‘%Comment%’ OR ScripConditions_2.ApplicableTransTypes LIKE ‘%Any%’) AND (main.Disabled = ‘0’)
2016-12-22 13:26:36 CET [31696-15] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-16] rt_rt@rt STATEMENT: SELECT main.* FROM Scrips main JOIN ObjectScrips ObjectScrips_1 ON ( ObjectScrips_1.Scrip = main.id ) JOIN ScripConditions ScripConditions_2 ON ( ScripConditions_2.id = main.ScripCondition ) WHERE (ObjectScrips_1.ObjectId = ‘0’) AND (ObjectScrips_1.Stage = ‘TransactionCreate’) AND (ScripConditions_2.ApplicableTransTypes LIKE ‘%Comment%’ OR ScripConditions_2.ApplicableTransTypes LIKE ‘%Any%’) AND (main.Disabled = ‘0’) GROUP BY main.id ORDER BY MIN(ObjectScrips_1.SortOrder) ASC
2016-12-22 13:26:36 CET [31696-17] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-18] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-22 13:26:36 CET [31696-19] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-20] rt_rt@rt STATEMENT: SELECT * FROM Transactions WHERE id = $1
2016-12-22 13:26:36 CET [31696-21] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-22] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-22 13:26:36 CET [31696-23] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-24] rt_rt@rt STATEMENT: UPDATE Tickets SET LastUpdated=$1 WHERE id=$2
2016-12-22 13:26:36 CET [31696-25] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-26] rt_rt@rt STATEMENT: UPDATE Tickets SET LastUpdated=$1 WHERE id=$2
2016-12-22 13:26:36 CET [31696-27] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-28] rt_rt@rt STATEMENT: UPDATE Tickets SET LastUpdated=$1 WHERE id=$2
2016-12-22 13:26:36 CET [31696-29] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-30] rt_rt@rt STATEMENT: SELECT * FROM Tickets WHERE id = $1
2016-12-22 13:26:36 CET [31696-31] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-32] rt_rt@rt STATEMENT: SELECT * FROM Users WHERE id = $1
2016-12-22 13:26:36 CET [31696-33] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-34] rt_rt@rt STATEMENT: SELECT * FROM Users WHERE id = $1
2016-12-22 13:26:36 CET [31696-35] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-36] rt_rt@rt STATEMENT: SELECT * FROM Principals WHERE id = $1
2016-12-22 13:26:36 CET [31696-37] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-38] rt_rt@rt STATEMENT: SELECT main.* FROM Attributes main WHERE (main.ObjectId = 1900) AND (main.ObjectType = ‘RT::User’) ORDER BY main.id ASC
2016-12-22 13:26:36 CET [31696-39] rt_rt@rt ERROR: current transaction is aborted, commands ignored until end of transaction block
2016-12-22 13:26:36 CET [31696-40] rt_rt@rt STATEMENT: SELECT main.* FROM Attributes main WHERE (main.ObjectId = 1900) AND (main.ObjectType = ‘RT::User’) ORDER BY main.id ASC

It seems to me, that a transaction - comment and owner change is processed
by one RT server process and concurrently runs another web server
process gathering data for ticket history. I have a rather long ticket
history now. I added many comments already. The probability of
transaction collision is very high, so the problem occurs every time.

Are there any changes in RT between 4.2 and 4.4 toward loading web page
asynchronously? Is it possible data are loading from browser while
a modify transaction is in progress yet.

Zito