Command timeout not honored for stored procedure call

Posts   
 
    
Sena
User
Posts: 22
Joined: 21-Jul-2021
# Posted on: 21-Jul-2021 17:08:49   

We just migrated from 5.1 to 5.8 and are experiencing some issues with the command timeout not being used correctly.

Snippet of 5.1:

// SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore
using System.Data;
using System.Data.Common;

/// <summary>
/// Creates the stored procedure call command for the stored proc specified.
/// </summary>
/// <param name="storedProcedureToCall">The stored procedure to call.</param>
/// <param name="parameters">array of parameters to pass</param>
/// <returns>ready to use DbCommand</returns>
protected virtual DbCommand CreateStoredProcedureCallCommand(string storedProcedureToCall, DbParameter[] parameters)
{
    DbCommand command = GetDbProviderFactoryInstance().CreateCommand();
    string procName = command.CommandText = CreateCorrectStoredProcedureName(storedProcedureToCall);
    command.Connection = GetActiveConnection();
    if (IsTransactionInProgress)
    {
        command.Transaction = PhysicalTransaction;
    }
    command.CommandType = CommandType.StoredProcedure;
    if (CommandTimeOut > 0)
    {
        command.CommandTimeout = CommandTimeOut;
    }
    command.Parameters.AddRange(parameters);
    return command;
}

So the command timeout is set based on the property of the DataAccessAdapterCore.CommandTimeOut.

In 5.8 the creation of the command is delegated to the QueryCreationManager:

// SD.LLBLGen.Pro.ORMSupportClasses.Adapter.QueryCreationManager
using System.Data;
using System.Data.Common;

/// <summary>
/// Creates the stored procedure call command for the stored proc specified.
/// </summary>
/// <param name="storedProcedureToCall">The stored procedure to call.</param>
/// <param name="parameters">array of parameters to pass</param>
/// <returns>ready to use DbCommand</returns>
protected internal virtual DbCommand CreateStoredProcedureCallCommand(string storedProcedureToCall, DbParameter[] parameters)
{
    DbCommand command = _containingAdapter.GetDbProviderFactoryInstance().CreateCommand();
    if (command == null)
    {
        return null;
    }
    string procName = command.CommandText = CreateCorrectStoredProcedureName(storedProcedureToCall);
    command.Connection = _containingAdapter.GetActiveConnection();
    if (_containingAdapter.IsTransactionInProgress)
    {
        command.Transaction = _containingAdapter.PhysicalTransaction;
    }
    command.CommandType = CommandType.StoredProcedure;
    if (CommandTimeOut > 0)
    {
        command.CommandTimeout = CommandTimeOut;
    }
    command.Parameters.AddRange(parameters);
    return command;
}

The QueryCreationManager assigns its own CommandTimeOut to the command but that CommandTimeOut is only set once in the constructor of the QueryCreationManager and not related to the command timout as managed on the "_containingAdapter".

Should QueryCreationManager not simply use the _containingAdapter.CommandTimeOut instead of using (and having) its own member?

Best, Dick

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 22-Jul-2021 10:24:12   

Looks like a bug. We'll look into it. Normal queries are wired to the connection in a central place and will pick up the timeout there from the adapter, stored procs bypass that and indeed won't get the actual timeout set.

(edit) That whole timeout property in the query creation manager seems to be bogus. A left over of the refactoring which can be removed. thanks for pointing this out!

Frans Bouma | Lead developer LLBLGen Pro
Sena
User
Posts: 22
Joined: 21-Jul-2021
# Posted on: 22-Jul-2021 10:31:28   

Otis wrote:

Looks like a bug. We'll look into it. Normal queries are wired to the connection in a central place and will pick up the timeout there from the adapter, stored procs bypass that and indeed won't get the actual timeout set.

Thanks for the update, hope you can fix it in the coming weeks so we can upgrade to that fix... if not, let us know so we can downgrade again (in that case, in which version was this bug in introduced?).

Best, Dick

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 22-Jul-2021 10:34:37   

Oh you'll have a fix in an hour simple_smile Stay tuned

Frans Bouma | Lead developer LLBLGen Pro
Sena
User
Posts: 22
Joined: 21-Jul-2021
# Posted on: 22-Jul-2021 10:35:48   

Otis wrote:

Oh you'll have a fix in an hour simple_smile Stay tuned

Awesome!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 22-Jul-2021 11:23:14   

See the 5.8.3 hotfix build which should fix your problem. It's on nuget and the my account -> 5.8 -> hotfix downloads

Frans Bouma | Lead developer LLBLGen Pro
Sena
User
Posts: 22
Joined: 21-Jul-2021
# Posted on: 22-Jul-2021 13:11:53   

Otis wrote:

See the 5.8.3 hotfix build which should fix your problem. It's on nuget and the my account -> 5.8 -> hotfix downloads

Like a charm, thanks!

Joe Onesto
User
Posts: 1
Joined: 06-Aug-2021
# Posted on: 06-Aug-2021 18:40:04   

Otis wrote:

See the 5.8.3 hotfix build which should fix your problem. It's on nuget and the my account -> 5.8 -> hotfix downloads

Hi Otis,

We've run into the same issue, upgrading from 5.7.3 to 5.8.2. Is the fix for this issue currently the only change in the 5.8.3 hotfix prerelease, or are there additional changes as well? Thanks in advance.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 07-Aug-2021 09:31:05   

5.8.3 has currently only 1 change, this one.

Frans Bouma | Lead developer LLBLGen Pro