Why would connection pooling cause problems with a trigger?

Question

This is a strange one. We have an app that deletes a row in a database table, and this table has a delete trigger on it. The row gets deleted every time the app is run, yet the trigger only fires intermittently. It's not that the trigger is failiing in some way - it just doesn't get called at all. If I issue the same delete command in PL/SQL developer then the trigger fires every time.
Several hours later and out of desparation I tried turning off connection pooling via the app's connection string, and found that the trigger now fires every time. Any ideas what might be causing this behaviour? I can reproduce/fix the issue every time simply by setting "Pooling" to true or false!
We are using Oracle 11g and ODP.Net v4.112.2.0.
Thanks in advance
Andrew

Answer 1

More information: I've now been able to reproduce this issue in a small .Net app, and can make it fail in a more consistent manner (which I'll explain later). While it's still too large to post the entire code here, I can summarise what the app does in pseudo-code:-
for(int i = 1; i <= 10; i++) // Run the test a number of times
// Step 1 - Delete rows from the table with the delete query in question
Execute non-query "delete from test_table";
Wait 1 second
// Step 2 - Check that the delete actually happened
Execute reader "select count(*) from test_table"
Display the count
// Step 3 - Check that the delete trigger inserted some rows into a "logging" table. This is my method of "tracing" - I added a basic insert to the start of each trigger section, as mentioned in my previous post.
Execute reader "select count(*) from my_logging_table"
Display the count
// Reinstate the test data
Execute non-query "<insert rows back into test_table>"
Wait 1 second
For info the connection string is fairly basic:- "Data Source=<tns name>;User Id=<foo>;Password=<bar>"
Some points of interest:-
- When running the above test app, the trigger successfully fires on the very first iteration (i.e. "Step 3" displays a non-zero count from the logging table). All subsequent iterations fail ("Step 3" displays the same count each time).
- If I turn off connection pooling (by adding "Pooling=false" to the connection string), the trigger runs on every iteration (i.e. "Step 3" displays an ever-incrementing record count).
- Regardless of whether it works or fails, the deletion in step 1 does take place (confirmed by "Step 2" displaying a count of zero).
- I added the waits after the non-query calls to see if that made a difference, but it doesn't. I can change these to 10 seconds or more and it will have no effect on the issue.
The "Execute non-query" method uses code along these lines:-
using (var conn = new OracleConnection(ConnString))
conn.Open();
using (var cmd = conn.CreateCommand())
cmd.CommandText = sql;
cmd.CommandType = CommandType.Text;
result = cmd.ExecuteNonQuery();
conn.Close();
return result;
While the "Execute reader" method looks like this:-
var conn = new OracleConnection(ConnString);
conn.Open();
var cmd = conn.CreateCommand();
cmd.CommandText = sql;
cmd.CommandType = CommandType.Text;
return cmd.ExecuteReader(CommandBehavior.CloseConnection);
The calling code in the for loop, wraps the returned reader in a using clause like this:-
using (var reader = ExecuteReader("<sql>"))
This will dispose of the reader, which will in turn close/dispose the connection (due to the CommandBehavior.CloseConnection parameter passed to ExecuteReader).
Interestingly, if the reader isn't disposed of then the problem becomes more intermittent (the trigger will fire perhaps 25% of the time). This is what's happening in our unit test harness. By ensuring the reader/connection is closed and disposed (which common sense would say should improve matters), the trigger only fires on the very first iteration of the loop. The plot thickens.