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;
}
 
Search WWH ::




Custom Search