Would something like
T1
T2
R(A)
W(A)
R(B)
W(B)
COMMIT
COMMIT
be considered a conflict that makes the schedule non-serializable, but not an interference?
I thought it might be inconsistent analysis, but to be so I think one transaction would have to do only the reading and the other would do the writing.
Related
Suppose we have 2 transactions as T1, T2 with T2 doing dirty read on data modified by T1 and committing before T1. Now suppose T1 fails and is rolled back. My question is- Since T2 is committed, changes made by T2 are transferred from shared buffer to original database or not(Since I have read that changes made by a transaction are made permanent to original db once transaction commits)? And if they are transferred to original database, then how will T1 rollback and get previous value of data item (which was read dirty by T2)? By its buffer or original database?
Unless you are specifically calling a dirty read by setting the isolation level, then this sort of problem simply can not happen. That is the whole idea of a transaction. T2 will be locked out of the row if T1 has updated it. If you are allowing dirty reads by setting set transaction isolation level read uncommitted then the handling of the data is up to you, usually by using a rowversion which your T2 checks hasnt changed before it commits.
I was wondering what happens to a transactions that got blocked by another transaction?
It will best to work through an example, say I have two transactions - T1 and T2 and following scenario:
T1 ........................................................ T2
Lock DB object
Read Q ..................................................Lock Q (T2 is blocked)
Write Q
Unlock Q
So does the T2 is un-blocked after T1 is done or is it forever lost? I used to think that T2 was sent into a wait queue and waits there for its turn.
Thank you anyone who would clarify this concept to me :)
There are two common things that happen in this case:
T2 waits until T1 releases the lock. How this is implemented depends on the database software (and potentially the locking primitives provided by the OS).
T2 gets aborted when it tries to lock Q and finds that it is already locked. (Ex. for Oracle, an UPDATE or LOCK TABLE statement issued with the NOWAIT option.)
Having T2 "lost forever" would be a bug in the database engine.
An interesting read about Oracle's locking strategies: How Oracle Locks Data. (That whole chapter, Data Concurrency and Consistency, is interesting if you're studying these database aspects. Note that these details are highly database dependent. What you read there will not apply directly to SQL Server, DB2 or MySQL for instance.)
I did not find explicit sqlite locking commands before inserting or updating rows into the table. Does sqlite handle the locking mechanism on it own?
The pager module described in http://sqlite.org/lockingv3.html handles the locking mechanism. But I am not sure if there are any commands that the user can use to explicitly lock the tables. Please advice.
Thanks
As far as I know there are no dedicated sqlite commands to control locking. However you can get sqlite to lock the database using create transaction. For instance:
BEGIN IMMEDIATE TRANSACTION;
...
COMMIT TRANSACTION;
BEGIN EXCLUSIVE TRANSACTION;
...
COMMIT TRANSACTION;
If you read the documentation I linked you should get a better idea on the difference between IMMEDIATE & EXCLUSIVE transactions.
It might be worth noting that the locks in sqlite apply to the whole database and not just individual tables, unlike the LOCK TABLE statement in other sql databases.
SQLite does whatever locking is necessary in order to implement the transaction scheme that your SQL statements describe. In particular, if you don't describe any then you get auto-commit behavior, with a lock held for the duration of each statement and then dropped as the statement finishes. Should you need longer transactions (often true!) then you ask for them explicitly with BEGIN TRANSACTION (often shortened to BEGIN) and finish with COMMIT TRANSACTION (or ROLLBACK TRANSACTION). The transaction handling is frequently wrapped for you by your language interface (as this makes it considerably easier to get right, coupling the transaction lifetime to a code block or method call) but at the base level, it comes down to BEGIN/COMMIT/ROLLBACK.
In short, you've got transactions. Locks are used to implement transactions. You don't have raw locks (which is a good thing; they're rather harder to get right than you might think from first glance).
i start with a simple question:
according to Dirty Read definition in
Wikipedia
and Msdn :
we have 2 concurrent transactions, T1 and T2
Dirty Reads Occur in ,when T1 is Updating a row and T2 is reading row that "is not Committed yet" by T1
but at Read Committed Level shared locks are released as soon as the data is read (not at the end of the transaction or even the end of the statement
then how Read Committed prevents Dirty Reads?
Bkaz as soon as the share lock released on updated row T2 can read the updated row and t1 can rollback the whole operation,,then we have a dirty read on the hand of t1
It prevents the dirty read because T1 has a lock on the row, so T2 can't read the "not yet committed" row that could be rollbacked later.
The problem Read Committed tries to resolve is:
T1 creates a transaction and writes something
T2 reads that something
T1 rollback the transaction
now T2 has a data that didn't really ever existed.
Depending on how the DB is structured, there are two "good" possibilities:
T1 creates a transaction and writes something
T2 waits for T1 to end the transaction
or
T2 reads a "snapshot" of how the DB was BEFORE T1 began the transaction (it's called Read committed using row versioning)
(the default on MSSQL is the first option)
Here for example there is a comparison of the various isolation levels: http://msdn.microsoft.com/en-us/library/ms345124(SQL.90).aspx (read under Isolation Levels Offered in SQL Server 2005)
When SQL Server executes a statement at the read committed isolation level, it acquires short lived share locks on a row by row basis. The duration of these share locks is just long enough to read and process each row; the server generally releases each lock before proceeding to the next row. Thus, if you run a simple select statement under read committed and check for locks (e.g., with sys.dm_tran_locks), you will typically see at most a single row lock at a time. The sole purpose of these locks is to ensure that the statement only reads and returns committed data. The locks work because updates always acquire an exclusive lock which blocks any readers trying to acquire a share lock.
Ripped from here
When a SQL client issues the following command:
select * into tbl2
FROM tbl1 (nolock)
WHERE DateCreated < '2009/01/01'
does it mean that the command won't lock tbl1 or it won't be blocked by other uncommitted transactions made to tbl1?
Update:
[NOLOCK]: Specifies that dirty reads are allowed. No shared locks are issued to prevent other transactions from modifying data read by the current transaction, and exclusive locks set by other transactions do not block the current transaction from reading the locked data.
REF: MSDN
It means the first; you're not taking out any locks and therefore the second; you wont be blocked by other open transactions. See MSDN docs on table hints.
Here's a link to the MSDN docs on transaction isolation levels - might be useful if you're considering using NOLOCK. NOLOCK puts the SQL statement at isolation level read uncommitted. If you have a multi-statement transaction you may be able to set the isolation level at a lower level for the majority of the transaction and raise it where needed, rather than lowering it just on one or more statements in the transaction.
Both. And it will also read uncommitted data from other [uncommitted] transactions (if any).