Re: what is the rationale for not allowing LOCK TABLES in a stored procedure

Mogens Melander <[email protected]> Sun, 19 Aug 2018 01:32:13 +0700
Newsgroups gmane.comp.db.mysql.general
Organization Fumlersoft
Message-ID <[email protected]>
Guys,

I think I remember this from way back.

You could ask for a lock, and get an OK if it is safe.

Something like, if there is pending transactions, on your target tables,
you would get a NO.

But then again. I could be wrong, and Shawn is the authority on this.

On 2018-08-18 23:59, shawn l.green wrote:
> Hello Jeff,
> 
> On 8/13/2018 12:05 PM, [email protected] wrote:
>> Hello, I have read through several pages of the reference manual, and
>> I've seen several instances where it is stated that LOCK TABLES (and
>> UNLOCK TABLES) is not allowed in a stored procedure, but so far, I
>> haven't found an explanation as to *why* that is. Could someone please
>> enlighten me?
>> 
>> Thanks
> 
> Normally, the list is more responsive than this. This is a pretty easy
> question and someone usually handles those before I need to step in as
> a backstop.
> 
> The key why you cannot execute a LOCK TABLE command within a stored
> program is here:
> https://dev.mysql.com/doc/refman/5.7/en/lock-tables-and-transactions.html
> ###
> LOCK TABLES is not transaction-safe and implicitly commits any active
> transaction before attempting to lock the tables.
> ###
> 
> Stored programs execute under the scope of the transaction in which
> they are started. That determines which sets of rows are "visible" to
> the routine and sets boundaries on what may be committed or rolled
> back should the need arise.
> 
> (a simple example)
> * your session: START TRANSACTION
> * your session: ...other data activity ...
> * your session (INSERT ... )
>   * causes an INSERT trigger to fire
>     * which calls a stored procedure
> 
> If that stored procedure or that trigger called a LOCK TABLE command,
> it would forcibly COMMIT the existing transaction you had been working
> within until that moment.  Your half-completed work would have become
> fully committed even if a later step had needed you to issue a
> ROLLBACK command.
> 
> Note, even if you are not in a multi-statement transaction that any
> stored programs called by or executed within the scope of your user
> command are part of that little mini (auto-committed) transaction.
> 
> Does that help?
> 
> --
> Shawn Green
> MySQL Senior Principal Technical Support Engineer
> Oracle USA, Inc. - Hardware and Software, Engineered to Work Together.
> Office: Blountville, TN

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql