Hi,
Sinisa requests to change WL#3561 (transactional LOCK TABLE) so that
READ/WRITE locks are converted to SHARE/EXCLUSIVE locks for
transactional tables.
Rationale: Users won't need to change their applications to profit from
transactional table locks.
Sinisa says this change had been agreed between Heikki, Monty and him.
Possible disadvantage: This is a change in behavior. READ/WRITE locks on
transactional tables would go away at transaction end. This might be no
serious problem. Applications that rely on table locks to persist past
the end of transactions might be "broken". OTOH, there might exist such
"broken" applications. And they might not be that "broken". No idea if
we should risk to break such. Hence I need architectural approval for
such a change.
Another question is, how to treat table locks, that include
non-transactional *and* transactional tables. If we would still convert
locks on transactional tables, then part of the lock would go away at
transaction end, while another part would persist. Is that fine? Or
shall we implicitly unlock the whole thing at transaction end, if we
converted a part of it to a transactional lock?
Would a compromise be acceptable? To convert to transactional locks
*only* if *all* tables included in the lock are transactional?
Effort: Though implementation of the mentioned options might not be a
big task, thorough testing will eat much time, depending on the
complexity of the implemented behavior. The current behavior is very
simple and its test takes rank 790 of 850 in the main test suite (>1000
lines, alone the innodb specific test).
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
