Uploaded image for project: 'Couchbase .NET client library'
  1. Couchbase .NET client library
  2. NCBC-2388

Ensure that prepared statements that are previously created are not retried

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Duplicate
    • 3.0.0-beta.4
    • 3.0.1
    • library
    • None
    • 1

    Description

      "XXX is using named prepared statements instead of adhoc=false. This way they can better manage the lifecycle of the prepareds and reference by name, etc. They have logic build into the application that will attempt to execute the prepared (i.e. EXECUTE name_of_prepared) and catch a prepared not found exception, prepare the query and then reexecute.

      This is safety logic that is in place in the application, as externally they have a script that automatically attempts to prepare everyone of their queries whenever they do a build.

      However, retries make for a long delay as the queries timeout instead of immediately returning with a failed prepared query status/error."

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            You may want to chat with Michael Nitschinger on this, as some recent findings in compat with prepared statements may come into play. Whatever we do should be codified in the sdk-rfc across all clients.

            ingenthr Matt Ingenthron added a comment - You may want to chat with Michael Nitschinger on this, as some recent findings in compat with prepared statements may come into play. Whatever we do should be codified in the sdk-rfc across all clients.

            This is an interesting problem which we haven't discussed before - the user managing their prepared statements. It is definitely not trivial given all the cases outlined in our enhanced prepared statements rfc.

            I'm not sure I understand the reason " This way they can better manage the lifecycle of the prepareds and reference by name, etc" .. do we have more information on why our current approach is not sufficient for them?

            daschl Michael Nitschinger added a comment - This is an interesting problem which we haven't discussed before - the user managing their prepared statements. It is definitely not trivial given all the cases outlined in our enhanced prepared statements rfc. I'm not sure I understand the reason " This way they can better manage the lifecycle of the prepareds and reference by name, etc" .. do we have more information on why our current approach is not sufficient for them?

            Michael Nitschinger it comes down to indexes/queries as they change over time. for example i have Query1 and Index1, it is prepared and there is a single instance of that prepared instead of duplicate instances of the same prepared for each instance of the application. The DBA decides change Index1 to be "more optimized" and deploys a new index. The query is using "Index1" still. By using named prepareds they could go in and delete just that single instance from system:prepareds, which the application would then recognize the prepared is not there and reprepare it. If they were using adhoc=false, they would have to delete all system:prepareds or write a complex LIKE style query to find ones where a given query matched.

            aaron.benton Aaron Benton added a comment - Michael Nitschinger it comes down to indexes/queries as they change over time. for example i have Query1 and Index1, it is prepared and there is a single instance of that prepared instead of duplicate instances of the same prepared for each instance of the application. The DBA decides change Index1 to be "more optimized" and deploys a new index. The query is using "Index1" still. By using named prepareds they could go in and delete just that single instance from system:prepareds, which the application would then recognize the prepared is not there and reprepare it. If they were using adhoc=false, they would have to delete all system:prepareds or write a complex LIKE style query to find ones where a given query matched.
            ingenthr Matt Ingenthron added a comment - - edited

            Workaround if needed: use adhoc=true and use the logic of manually purging prepared statements.

            ingenthr Matt Ingenthron added a comment - - edited Workaround if needed: use adhoc=true and use the logic of manually purging prepared statements.

            Deferring to 3.0.1 as this can be worked around at the moment.

            ingenthr Matt Ingenthron added a comment - Deferring to 3.0.1 as this can be worked around at the moment.
            jmorris Jeff Morris added a comment - NCBC-2451

            People

              jmorris Jeff Morris
              jmorris Jeff Morris
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty