Tag Info

New answers tagged

1

You have to understand that the underlying protocol that you're using to send dta(http://en.wikipedia.org/wiki/Transmission_Control_Protocol). The TC-Protocol is designed to deal with network breaks. Ultimately if you send a transmission to the remote server saying, for instance "insert into table (id, name) values (1, 'test');" then the TC-Protocol will ...


1

In general when running queries (SQL Statements) against a database you want all of the statements to successfully completed and if they do not revert data to what is was before you ran the sql statement. The overall concept you are looking for is ACID In order to provide this functionality, Databases generally support the concept of a transaction. When ...


0

I'm not 100% sure I understand your question but anyway. Generally there's no need to wrap SELECT statements in transactions because they are read only, although you can specify the isolation level you want the SELECT to use (READ UNCOMITTED for instance). See here for a question about locks caused by SELECT statements in MySQL and how to change the type of ...


1

CREATE PROCEDURE `t`(IN `r` TINYINT, OUT `l` TINYINT, OUT `z` TINYINT) LANGUAGE SQL NOT DETERMINISTIC CONTAINS SQL SQL SECURITY DEFINER COMMENT '' BEGIN DECLARE exit HANDLER FOR SQLEXCEPTION, SQLWARNING BEGIN SET l = -1; SET z = -1; ...


2

You can set SERIALIZABLE as the default isolation level in postgresql.conf: default_transaction_isolation = 'serializable' This may confuse clients that assume READ COMMITTED isolation, so IMO it's better to set it explicitly in your sessions. As for the rest, per the manual: The DEFERRABLE transaction property has no effect unless the transaction is ...


0

If you are totally sure about the separation status of your data, you can set the global isolation level to READ COMMITTED or even to READ UNCOMMITTED. The first blocks less from the index, which should be enough in your case. The second one arranges for all SELECT statements to be non blocking. This is as low as you can go. Whatever you choose, you should ...


1

Introduction to transactions and savepoints In your scenario "Creating a new user" the basic process could be the following: BEGIN; INSERT INTO `users` (`username`, `password`, ...) VALUES ("me", "XXX", ...); SET @userid := LAST_INSERT_ID(); INSERT INTO `profile_pictures` (`user_id`, `profile_picture_path`) VALUES (@userid, ...


1

You could implement all your inserts on those tables via stored procedures. That would allow you to execute your check_percentage process at the end of said stored procedure. It would also allow you to impose additional conditions on said execution.



Top 50 recent answers are included