Doing
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE STATE = "executing";
It contains a column Id which is the Id number of all the threads currently running. Now in my MySQL procedure, at the beginning I wish to know the ID of the thread executing it. What query will return the ID of the thread running the procedure?
Secondly: I wish to know it because, the queries in my application are quite long running. I want to automate the process that as soon I get a fresh request, my application will cancel the already running query by Kill query someID. For this I need to know the ID of already running procedure. Does Kill query command affect the stability? As per documentation, it looks safe as it only sets a flag and connection is intact.
Use the CONNECTION_ID() function.
http://dev.mysql.com/doc/refman/5.5/en/information-functions.html#function_connection-id
Related
I have a database query which deletes from database with some given conditions. The query is being initiated by an endpoint which timeouts if the query takes a long time (which it does). The service which calls this endpoint needs to do some other tasks after this operation is successful. So we need to know when this query completes. The query is :
DELETE FROM foo WHERE creation_time BETWEEN ? AND ? AND bar_id = ?
How do I know when the query completes? I am using jdbctemplate for querying the database.
I thought of one option but now sure how the between query works internally.
I thought of creating a status endpoint which checks if the query is still running? The endpoint will check if there is any row in foo where creation_time = FROM and bar_id = id.
But I don't know how mysql handles the BETWEEN query internally. If it starts deleting from the FROM or the TO or anything in between.
Short question : How do I check if my query is still running or finished with jdbctemplate?
You can execute the SHOW FULL PROCESSLIST; command. See the MySQL docs for a good description of the command.
This will show all running threads, along with the query that is currently executing and the time that it has been running.
Then parse the output to see if your query is still running.
Hope this helps.
What is written on the PHP Manual and also one comment from the manual says:
Closes a prepared statement.
mysqli_stmt_close() also deallocates
the statement handle. If the current
statement has pending or unread
results, this function cancels them so
that the next query can be executed.
Comment:
if you are repeating an statement in
an loop using bind_param and so on
inside it for a larger operation. i
thougt id would be good to clean it
with stmt->close. but it broke always
with an error after aprox. 250
operations . As i tried it with
stmt->reset it worked for me.
Here I don't understand what is the meaning of "prepared statement
has pending or unread results"?
An RDBMS that is running a query can return data before the entire dataset has been processed. There can also be records that it has not read yet.
Both the records that are already read and the ones that are pending must be saved in some resource in the database server, usually called a 'cursor'.
You execute the application code statement that reads these records from the server's cursor and into your application's memory, with PHP's MySQi wrappers those are the called the fetch methods.
Now after executing a query, you are not obliged to fetch any or all these results. So either way, after reading the results of the query or not, executing mysqli_stmt_close() tells the server it can discard the cursor, i.e. remove the already read records from its memory and cancel the optionally still running query.
So:
Unread results: fetched from the database, but not read by the client.
Pending results: records that will be included in the result set once the query runs to completion.
Perhaps the title is a little misleading, so I'll explain my question in further detail. Obviously the queries inside of the procedure are executed synchronously and in order, but are procedures themselves executed synchronously?
Lets say I have a procedure called "Register" which handles a couple of queries, for example it looks like this:
BEGIN
DECLARE account_inserted INT(11);
INSERT INTO accounts (...) VALUES (...);
SET account_inserted = LAST_INSERTED_ID(); # <------
QUERY using account_inserted...
QUERY using account_inserted...
QUERY using account_inserted...
...
END
Now lets say that there were numerous requests to register coming in at the same time (For example purposes let us say around 200-300 requests) would it execute all of the procedures in order? Or is it possible would the LAST_INSERTED_ID() variable to conflict with a row inserted from another procedure that is being executed in parallel?
You're muddling three things:
Whether MySQL executes procedures synchronously
This could be interpreted to mean either "does MySQL wait for each command within a procedure to complete before moving on to the next?" or "does MySQL wait for the entire procedure to complete before accepting further instructions from the connection that invoked the CALL command?". In both cases, the answer is "yes, it does".
Whether invocations of MySQL procedures are executed atomically
As with any other series of commands, commands within procedures are only atomic if performed within a transaction on tables that use a transactional storage engine. Thus a different connection may well execute another INSERT between the INSERT in your procedure and the command that follows.
Whether LAST_INSERTED_ID() is guaranteed to return the value generated by the immediately preceding INSERT command in the procedure?
Yes, it is. The most recent insertion ID is maintained on a per-connection basis, and as described above the connection waits for CALL to complete before further commands are accepted.
The ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.
https://dev.mysql.com/doc/refman/5.5/en/information-functions.html#function_last-insert-id
I'm not sure if this is an issue with phpMyAdmin, or that I'm not fully understanding how transactions work, but I want to be able to step through a series of queries within a transaction, and either ROLLBACK or COMMIT based on the returned results. I'm using the InnoDB storage engine.
Here's a basic example;
START TRANSACTION;
UPDATE students
SET lastname = "jones"
WHERE studentid = 1;
SELECT * FROM students;
ROLLBACK;
As a single query, this works entirely fine, and if I'm happy with the results, I could re-run the entire query with COMMIT.
However, if all these queries can be ran seperately, why does phpMyAdmin lose the transaction?
For example, if I do this;
START TRANSACTION;
UPDATE students
SET lastname = "jones"
WHERE studentid = 1;
SELECT * FROM students;
Then this;
COMMIT;
SELECT * FROM students;
The update I made in the transaction is lost, and lastname retains its original value, as if the update never took place. I was under the impression that transactions can span multiple queries, and I've seen a couple of examples of this;
1: Entirely possible in Navicat, a different IDE
2: Also possible in PHP via MySQLi
Why then am I losing the transaction in phpMyAdmin, if transactions are able to span multiple individual queries?
Edit 1: After doing a bit of digging, it appears that there are two other ways a transaction can be implicitly ended in MySQL;
Disconnecting a client session will implicitly end the current
transaction. Changes will be rolled back.
Killing a client session will implicitly end the current
transaction. Changes will be rolled back.
Is it possible that phpMyAdmin is ending the client session after Go is hit and a query is submitted?
Edit 2:
Just to confirm this is just a phpMyAdmin-specific issue, I ran the same query across multiple seperate queries in MySQL Workbench, and it worked exactly as intended, retaining the transaction, so it appears to be a failure on phpMyAdmin's part.
Is it possible that phpMyAdmin is ending the client session after Go is hit and a query is submitted?
That is pretty much how PHP works. You send the request, it get's processed, and once done, everything (including MySQL connections) gets thrown away. With next request, you start afresh.
There is a feature called persistent connections, but that is as well doing it's clean up. Otherwise the code would have to somehow handle giving the same user the same connection. Which could prove very difficult given the way PHP works.
I am using Gearman workers to accept jobs from a MySQL database. The procedure for these workers getting a job is something like:
SELECT foo, bar FROM jobs WHERE job_id = 'foobarbaz' AND status = 'WAITING';
Now, if that query returns one row, then the worker knows its been given a valid job and proceeds to work on it. But of course the risk is while working on it another worker might take up the job, too.
To prevent this I'm thinking how can I atomically SELECT the data needed to proceed with the job as well as update the status of it if it was valid? I thought perhaps of doing the UPDATE on the row status with the job ID and then testing affected rows, but wasn't sure if there was a more sensible way to go about it.
Thanks.