Hi Nishant,
within a transaction locks may be upgraded, but never downgraded.
In your case the 1st statement will place a write lock and statements #2 and #3 don't need to set an additional lock.
If you started with #3 you might result in a (worst case dead-) lock when another session also requested a read lock on the same table.
You should avoid BT/ET and use Multi Statement Request instead, thus the optimizer knows about all locks in advance.
Multiple statements form one request when the next statement starts on the same line as the previous semicolon:
This is one transaction consisting of 5 seperate requests, i.e. 5 messages send across the network and independently optimized:
BT;
INSERT INTO <tab_C> SELeCt.... ; --statement 1
UPDATE <tabl_C>...........; --statement 2
Select * from table_C; - statement 3
ET;
But this is one transaction consisting of 3 statements within a single request, i.e. one message send across the network and optimized all together:
INSERT INTO <tab_C> SELeCt.... --statement 1
;UPDATE <tabl_C>........... --statement 2
;Select * from table_C; - statement 3
Dieter
Hi Nishant,
within a transaction locks may be upgraded, but never downgraded.
In your case the 1st statement will place a write lock and statements #2 and #3 don't need to set an additional lock.
If you started with #3 you might result in a (worst case dead-) lock when another session also requested a read lock on the same table.
You should avoid BT/ET and use Multi Statement Request instead, thus the optimizer knows about all locks in advance.
Multiple statements form one request when the next statement starts on the same line as the previous semicolon:
This is one transaction consisting of 5 seperate requests, i.e. 5 messages send across the network and independently optimized:
But this is one transaction consisting of 3 statements within a single request, i.e. one message send across the network and optimized all together:
Dieter