Re: all about transaction
From: Hugo Kornelis (hugo_at_pe_NO_rFact.in_SPAM_fo)
Date: 12/14/04
- Next message: Hugo Kornelis: "Re: Please explain why this Select doesn't fail"
- Previous message: Hugo Kornelis: "Re: [SQL update question]"
- In reply to: Deepson Thomas: "Re: all about transaction"
- Next in thread: Deepson Thomas: "Re: all about transaction"
- Reply: Deepson Thomas: "Re: all about transaction"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 14 Dec 2004 09:38:11 +0100
On Mon, 13 Dec 2004 21:05:03 -0800, Deepson Thomas wrote:
Hi Deepson,
>Hi steave. u gave an intresting answer and frankly it increased my number of
>doubts also :) .. so according to u the sql statements executes after
>begintrans is directly affecting the tables but sql server is maintaining all
>these details in the transaction log right ??
Yep.
> .... so where sql server is
>keeping all the old data to put back if we executed rollback or if we didnt
>called rollback.
The entries in the transaction log are used to restore old values on a
ROLLBACK. Likewise, during recovery after a system crash ALL uncommitted
transactions will be rolled back (from the transaction log).
> this transaction log is a physical file in the server or itz
>saves in memory ??
It's a physical file and SQL Server uses no caching for this file. This
ensures that no modifications can be lost, not even on a system crash or
power outage.
> and what if i saw the details updated by some transaction
>queries and if i did some calculations and stored in some other table but
>after that he rolledback all the old data will come back and the data on
>which i did the calculations wont be there
Default behaviour of SQL Server won't allow this. Normally, all data that
is modified in a transaction is also locked. No other connection is able
to read those rows until the modifying transaction is either committed or
rolled back.
If you *choose* to override this default behaviour by forcing read
uncommitted transaction isolation level, you'll have to be aware that you
might indeed be reading changes that will eventually be rolled back.
> na...and whatz Dan said like "read
>uncommitted" and all.... is there anything else like that ....
Yes, there are a total of four isolation levels:
* Read committed (the default)
* Read uncommitted (aka dirty read - described above)
* Repeatable read
* Serializable
The last two have the effect of keeping data locked even if it is only
used in a read operation. More details can be found in Books Online,
subject SET TRANSACTION ISOLATION LEVEL.
Best, Hugo
-- (Remove _NO_ and _SPAM_ to get my e-mail address)
- Next message: Hugo Kornelis: "Re: Please explain why this Select doesn't fail"
- Previous message: Hugo Kornelis: "Re: [SQL update question]"
- In reply to: Deepson Thomas: "Re: all about transaction"
- Next in thread: Deepson Thomas: "Re: all about transaction"
- Reply: Deepson Thomas: "Re: all about transaction"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|