Databases Reference
In-Depth Information
Note the detail—we use
table_alias_charset
to compare table names. It
will give a case-sensitive or case-insensitive comparison, depending on the
lower_case_table_names
MySQL configuration variable. To avoid bugs it is
important to use exactly the same case sensitivity rules as elsewhere in the server.
share = (STATIC_SHARE*)alloc_root(&table->s->mem_root,
sizeof(*share));
bzero(share, sizeof(*share));
share->name = strdup_root(&table->s->mem_root, table_name);
share->next = (STATIC_SHARE*)table->s->ha_data;
table->s->ha_data = share;
return share;
}
If no matching
STATIC_SHARE
is found in the list, we create a new one and link it
in. As all memory is allocated in the
TABLE_SHARE
memory root, it will be freed
automatically along with
TABLE_SHARE
. Very handy.
A thought about locking and concurrent accesses: In MySQL 5.1 a
table is opened under a mutex. We can safely access and modify
table->s->ha_data
and not worry about other threads. In later MySQL
versions this mutex is removed. It has improved the concurrency, but
our code is no longer correct. There is an easy fix though—these MySQL
versions provide a dedicated mutex
table->s->LOCK_ha_data
that we
will need to use to protect
table->s->ha_data
.
It seems logical to initialize
share->lock
directly in
find_or_create_share()
,
when a new
STATIC_SHARE
is created, but unfortunately MySQL will not give us a
chance to destroy it before freeing
STATIC_SHARE
along with
TABLE_SHARE
. Hence,
we have no choice but to maintain a usage counter for
STATIC_SHARE
and call the
initialization and destruction functions accordingly.
int ha_static_text::close(void)
{
if (--share->use_count == 0)
thr_lock_delete(&share->lock);
return 0;
}