Bug in the Editor 1.4.2 .NET libraries.

ahanssens@cps247.com

I'm using Editor 1.4.2 with the .NET libraries.

There's a bug in the Query.cs classes in the DataBaseUtil folder. I'm using the SQL Server version of the classes, but the relevant code seems to be the same in the other versions.

Part of the code in the Query._Exec() function looks like this:

        var dr = _stmt.ExecuteReader();
        dt.Load(dr);
        dr.Close();

The problem is that if an exception occurs during the call to dt.Load(), the data reader is never closed. As a result of the exception handling, we eventually end up in Query.Rollback(), which contains this code:

        _transaction.Rollback();
        _transaction.Dispose();
        _transaction = null;

When the code tries to call _transaction.Rollback(), another exception occurs: the transaction cannot be rolled back because a data reader is still open. This means that the line "_transaction = null" is never executed. Since _transaction is a static variable, this causes the Editor-related parts of the web application to become unusable until the web application's process is recycled. Any futher attempt to use the .NET libraries will cause Query.Transaction() to return the error "Already in a transaction. Please close the exisiting transaction first".

This problem can be fixed by changing all of the code that calls ExecuteReader() to have this structure:

        using (var dr = _stmt.ExecuteReader()) {
          dt.Load(dr);
        }

(Note that Query._Prepare() also calls ExecuteReader() and also needs to be changed.)

However, I don't understand why _transaction is a static variable. This means that only one Editor-related database operation can be in progress at a time across the entire web application. If two users both try to perform a database operation with the Editor at exactly the same time, one of them will get the "already in a transaction" error, even if they are working with completely different tables. I can avoid the error by gating access with a lock() statement or something similar, but that still removes all of the parallelism.

allan

Hi,

Thanks for your feedback on this - hugely appreciated!

The DataReader potentially not closing is a complete bug - I've just committed the required change and it will be in Editor 1.5.0.

Likewise the transaction parameter - to be honest I'm not sure what my thinking was when I made it static! Instead, for 1.5.0 it will be an internal property as part of the Database class - this means that multiple instances of the Database class can be made and since the Query class belongs to a specific Database instance it can refer back to that.

1.5.0 will be out next week!

Regards,
Allan