Project

General

Profile

Actions

Support #8608

open

Wt::Dbo: how to avoid creation of prepared statements?

Added by max p almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
06/01/2021
Due date:
% Done:

0%

Estimated time:

Description

Hello,

My application is doing a lot of "selects" to MySql db in the form:
session->find<MyType>().where(...).bind(...);
Every time a prepared statement is created, what causes, that in around 3h I got an exception from MySql that max. count of prepared statements has been reached.
I can't find any method to clear prepared statements.
Also using DirectBinding does not solve the issue.
The only thing is to destroy the session, but on the other hand, it is said and recommended to keep the session as a long-living object.

How can I disable the creation of prepared statements?

Kind regards,
Max.

Actions #1

Updated by Korneel Dumon almost 3 years ago

Hi,

Wt makes a cache of prepared statements to reuse them. So this should not be a problem unless you make many different queries (excluding different parameters of course). Is this the case?
If not, it would be helpful if you could provide an example to reproduce the issue.

There are some methods to directly interact with the MySQL connection, but it's best to avoid it if you can: https://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1Dbo_1_1backend_1_1MySQL.html

Korneel

Actions #2

Updated by max p almost 3 years ago

Hi,

thanks for the fast answer.
I've made a workaround like this:
I have made a custom connection class deriving from MySQL and I've overwritten those:

    void executeSql( const std::string& sql ) override
    {
        MySQL::executeSql( sql );
        MySQL::clearStatementCache();
    }
    void commitTransaction() override
    {
        MySQL::commitTransaction();
        MySQL::clearStatementCache();
    }

and it seems to solve the issue.

What I do is that I insert a lot of performance measurement into the database and refresh clients' last status timestamp. I think one of those is causing the problem.
I will try to make a standalone use case from the case I have at work. But most likely during the weekend.

Kind regards,
Max.

Actions

Also available in: Atom PDF