Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-8153

PreparedStatements broken when column family is recreated

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Duplicate
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Severity:
      Normal

      Description

      The scenario:
      1. Create a PreparedStatement which references some column family.
      2. Cache the PreparedStatement instance (afaik this is standard practice).
      3. Execute the statement - it works.
      4. Drop the column family.
      5. Recreate the column family.
      6. Execute the statement - it fails (and will forever fail).

      This scenario worked properly on earlier versions. As of 2.1.0, it's broken - the prepared statement seems to be bound to the deleted column family and is not re-bound to the new one. At a glance, this may be caused by CASSANDRA-5202.

      Workaround: client code must invalidate its PreparedStatement cache when a DROP query is executed (on column family, keyspace, and possibly others).

      The best fix would be to keep the cf_ids as an internal implementation detail, and make sure the query (which references the column family by name) continues to work by re-resolving the cf to the new one, rather than breaking client code due to this implementation detail.

      An alternative fix would be to document this code-breaking change and instruct clients to implement the workaround in their prepared statement caches.

      I'm not familiar with any of these internals (other than the several hours I spent trying to figure out why my unit tests started failing), so if anything in this report is incorrect, feel free to correct it

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                amichai Amichai Rothman
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: