Go Premium for a chance to win a PS4. Enter to Win

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 91
  • Last Modified:

MySQL concurrent procedures messing with same rows

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!
1 Solution
Olaf DoschkeSoftware DeveloperCommented:
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.
RalphAuthor Commented:
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 Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

Tackle projects and never again get stuck behind a technical roadblock.
Join Now