We recently upgraded from 5.9.2 to 5.12.0, and have noticed a change in behavior with how our Services are disposing of their database connections when a request has an uncaught exception.
This is in a .NET Framework 4.7.2 C# project utilizing .NET Standard 2.0 libraries.
Our endpoint processing in the Services roughly looks like this:
[Route("/api/some_endpoint", "POST")]
[DataContract]
[Api(Description = "An endpoint.")]
public class SomeDto { }
public class ResponseDto { }
public class SomeService : ServiceStack.Service
{
public ResponseDto Get(SomeDto requestDto)
{
using (var transaction = Db.OpenTransaction(IsolationLevel.ReadCommitted))
{
bool validationResult = ValidateRequest(Db, requestDto);
if (!validationResult)
{
throw new ValidationException();
}
DoStuff(Db);
transaction.Commit();
}
return new ResponseDto();
}
}
where Db is provided by an OrmLiteConnectionFactory using the PostgreSqlDialect.Provider that has been registered in our AppHost.
Those validation exceptions are then handled in an exception handler we assigned to the Apphost “UncaughtExceptionHandler”, which translates them to a meaningful error we send back in our response.
After our upgrade, throwing this ValidationException no longer is now longer closing/disposing our connection used, which remains open until the Postgres database sees a timeout on it. Before the upgrade these connection would be dropped after we sent our response.
This was detected in our automated testing, where we might have hundreds of invalid requests sent quickly, which then would clog up our database, hitting its limit for maximum concurrent connections and causing subsequent connections to fail.
Is this a defect, or an intentional change in behavior? And do you have any preferred way we should be ensuring these connections are properly disposed, so that they do not hang around like this?
If necessary, I can likely send you a small project to replicate this if this is insufficient to demonstrate the issue.
