summaryrefslogtreecommitdiffstats
path: root/storage/tokudb/doc/handlerton-lock
diff options
context:
space:
mode:
Diffstat (limited to 'storage/tokudb/doc/handlerton-lock')
-rw-r--r--storage/tokudb/doc/handlerton-lock82
1 files changed, 82 insertions, 0 deletions
diff --git a/storage/tokudb/doc/handlerton-lock b/storage/tokudb/doc/handlerton-lock
new file mode 100644
index 00000000..7a5c0b3f
--- /dev/null
+++ b/storage/tokudb/doc/handlerton-lock
@@ -0,0 +1,82 @@
+== Introduction ==
+
+MySQL interfaces with TokuDB through a set of plugins, which, at
+the time of this writing (October 2011) includes the tokudb storage
+engine plugin, the user data information schema plugin, and the
+user data exact information schema plugin. Each plugin provides
+initialize and de-initialize functions for mysql to call when
+they are installed or uninstalled by clients.
+
+== Problem ==
+
+It was originally discovered that the two information schema plugins
+would crash if the tokudb storage engine failed to init properly. The
+information plugins depend on the storage engine plugin, so a quick fix
+for this problem was to have the storage engine plugin's init function
+set a global flag if it failed. The information schema plugins could first
+check this flag before proceeding. This fixed the original problem, but
+the following still remain:
+
+ * a client connects, uninstalls tokudb storage engine, accesses
+ the tokudb user data/exact table.
+
+ * uninstall the tokudb engine plugin, drop a table, select from
+ it to see that it does not exist, then install the tokudb engine
+ to see that it has reappeared.
+
+ * any situation where one client is using any plugin while another
+ client modifies one.
+
+== Proposed solution ==
+
+Use a flag, call it tokudb_hton_initialized, that is set if the
+storage engine's init function suceeds. The information schema plugins
+will check that this flag is set before proceeding.
+
+To protect against client race conditions, use a reader-writer lock to
+protect the flag. Any clients which depend on the status of the flag
+grab a read lock. Clients that change the status of the flag grab a write
+lock. Using this flag and a protecting reader-writer lock, we can ensure
+that no client is under the assumption that the handlerton is usable
+while it is not, due to failure or uninstallation, etc.
+
+== Implementation ==
+
+{{{
+#!c
+
+static int tokudb_hton_initialized;
+
+// grab a write lock when changing the
+// hton_init flag
+tokudb_init_func() {
+ grab_hton_init_writelock();
+ ...
+ tokudb_hton_initialized = 1;
+error:
+ release_hton_init_writelock();
+}
+
+tokudb_end() {
+ grab_hton_init_writelock();
+ assert(tokudb_hton_initialized);
+ ...
+ tokudb_hton_initialized = 0;
+ release_hton_init_writelock();
+}
+
+// grab a read lock while assuming
+// the handlerton is usable
+//
+// same thing for user_data_exact
+tokudb_user_data_fill() {
+ grab_hton_init_readlock();
+ if (!tokudb_hton_initialized) {
+ // error
+ } else {
+ // fill the user data table
+ }
+ release_hton_init_readlock();
+}
+
+}}}