Long KODA Verb
Question
We are experiencing the problems you identified relating to the Long Koda Verb problem. Could you provide me with some explanation of this problem and how we might possibly overcome it in our application? We are experiencing this with some reports that have very complicated views where we are using up to 6 Unions of tables in the database.
Answer
The long koda verb problem has been in Rdb since V1.0. I've know about it since Rdb V3.0.
The issue is a combination of algorithms that are deep in Rdb's internals.
First, Rdb uses locks and blocking AST's to cordinate access at the buffer and page level. If process 1 reads a buffer, it takes out an exclusive lock on the buffer. If process 2 needs the same buffer, it attempts a lock, which kicks off a blocking Asynchronous System Trap (AST) to Process 1. Process 1 then takes out the appropriate page and record locks and reduces its buffer lock to the appropriate level. This is true for both read only and read write transactions. The only difference is the level to which locks get reduced. This is all transparent to your application.
The second piece is that Rdb ignores blocking ASTs for the life of a KODA verb. A KODA verb is a low level operation that needs to complete before interruption. The definition of a KODA verb is fairly obscure -- at least I've never gotten a good explanation of exactly what constitutes a KODA verb.
The third piece is that some KODA verbs can span a relatively long period of time. The examples I've seen tend to be joins that are doing sequential searches on several tables.
The symptoms of the problem are:
 | Read write transactions are waiting on read only transactions with a two-part DBkey -- aaa:ppp where aaa is a physical area and ppp is a page. |
| The KODA verb count in the I/O summary display is not increasing. This symptom will not be visible if there are other transactions happily accessing different areas of the database. |
The blocking will persist until one of two things happens. Either the R/O transaction completes the KODA verb or it flushes the buffer from its buffer pool. This problem is actually aggravated by large buffer pools -- it takes longer to flush the buffer.
The workarounds to the problem are minimal. Either tune the offending query so that it doesn't do long KODA verbs, reduce the buffers for the R/O transaction so it flushes the buffers sooner, or run the report at a time when it will not conflict with interactive users.
If you are using global buffers, you can reduce the allocate set for the R/O transaction and take advantage of the global buffering to reduce I/O.
In the case of your views with unions, Rdb may be reconstituting the entire view before it processes any of the criteria in the query against the view. There has been a lot of work in the last several versions on improving view optimization, but the engineers may not have solved the problem of very complex views yet. I haven't looked at that issue since Rdb V4.0.
Hope this helps -- Let me know if you have additional questions.
Cordially,
Keith W. Hare
JCC Consulting, Inc
