MySQL concurrent procedures messing with same rows

Posted on 2016-07-18
Last Modified: 2016-07-19
I have a couple long running SQL PROCs, on the order of 2 to 8 minutes and I need to have the operator able to run both simultaneously.

In the attached image you can see that I finally caught it in doing what I knew it would someday do.

My situation is USUALLY:

Check if a record exists via COUNT(*)
If not

In both cases, I also sometimes INS/UPD other tables.

This last criteria of affecting more than the one table, by my understanding rules out using SELECT FOR UPDATE as I need the other tables also synchronized.
(Yes, Innodb is in the correct transaction mode to support this.)

My questions.
1) Confirming my approach vs. FOR UPDATE or SHARED READ approaches.

The more interesting question:
2) I also have intensive auditing going on inside that IF/THEN within the TRANSACTION.

The auditing is done via a CALL to AuditThis(...) PROC.
2a)  Are procedure boundaries irrelevant WRT Transactions?

If relevant, then can I do the transaction in the primary PROC and remain in it once returned from AuditThis() ?

If irrelevant, it seems I need to not do a COMMIT within AuditThis().

2b)  If so, what's a good way to keep AuditThis() informed whether it is within a transaction?

The simple answer is 'do not commit within AuditThis()'.
But earlier I was having the two primary PROCs both calling AuditThis() and getting irregularities...

I may just skip any COMMITs w/in AuditThis() and do a COMMIT on return (if not in a Transaction),
    but if it ends out I can't get away with that at other times
    because calls to AuditThis() aren't always w/in a transaction,
I may have to conditionally COMMIT within AuditThis().

IFF I have to do that, I was thinking of using something like:
FROM zWithinTransaction ;

# Then

Open in new window

Have I gone over the edge on a goose chase?

Thanks all!
Question by:Ralph
LVL 29

Accepted Solution

Olaf Doschke earned 500 total points
ID: 41719227
I don't get what the screenshot has to do with your question. What do the two procs you talk of do? 1.1 What is the intent? 1.2 What is the reality? and 1.3 What is the problem you see.

From what you describe in general I assume your audit does not match what you see in tables, but it's hard to guess what the problem is from your screenshot alone.

In general, and that's not only true for MySQL, transactions do work for a single session and the isolation level of OTHER transactions determines whether they see changes not yet commited or not. Your own transaction usually isolates it's own changes from other transactions only and not from itself. In a "consistent read" snapshot mode you also don't read your own changes, you read the values from the snapshot time.

Transactions are not only valid for a single proc and stack level of your code, called functions also take part in them, so eg an Audit storing a new record also is rolled back, when you finally not commit but ROLLBACK, unless you audit by writing to a txt log file, for example. If you do the auditing calls to be able to track and profile what's going on including things finally rolled back, your auditing can't take part in transactions. In a certain sense it's correct the auditing of something not committed also disappear, indeed the ROLLBACK action also has to be audited to see what was audited was not committed.

Bye, Olaf.

Author Closing Comment

ID: 41719861
In case the other comment does not get saved, re-posted here.

Yes, I definitely should have taken a break and re-read what my over-focused mind was trying to convey...

Because function/proc invocations ARE within the scope of a transaction started before the call and commited after the call, I found out that I also have to suppress the COMMITs within those modules.

But sometimes, elsewhere in the code I WILL call the AuditThis() Proc when not in a transaction, so I had to work around that so that that (and others) will do the commits it needs.
I did that by inserting a record ,(COUNT(*) <> 0), into a 'flag' table and within the PROC using that to determine if I need to do a commit there or not.
Amazingly it does work!

My (1) question was whether I should use transactions or select for update/shared read.  I'd answered that myself and went for Transactions.

Thanks Olaf,

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction In this article, I will by showing a nice little trick for MySQL similar to that of my previous EE Article for SQLite (, A SQLite Tidbit: Quick Numbers Table Generation (…
This guide whil teach how to setup live replication (database mirroring) on 2 servers for backup or other purposes. In our example situation we have this network schema (see atachment). We need to replicate EVERY executed SQL query on server 1 to…
Although Jacob Bernoulli (1654-1705) has been credited as the creator of "Binomial Distribution Table", Gottfried Leibniz (1646-1716) did his dissertation on the subject in 1666; Leibniz you may recall is the co-inventor of "Calculus" and beat Isaac…
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…

685 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question