SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Use of Identity Property to Resolve Concurrency Issues


Use of Identity Property to Resolve Concurrency Issues

Author
Message
ketan.thacker
ketan.thacker
SSC Rookie
SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)

Group: General Forum Members
Points: 35 Visits: 49
Yes, I agree that there will be gaps in the sequence and also multiple users might update the same record. But don't you think the gaps would any way be there if for instance a sequence is used (as a feature of Sql Server 2011) as the first choice by the author and later on the transaction is rolled back.

So, I would not consider that having gaps in this case an issue which also moots the problem of updating the same record by multiple users.

My main focus was on removing the blocking issue.
arty 15255
arty 15255
Valued Member
Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)

Group: General Forum Members
Points: 61 Visits: 77
I also use SCOPE_IDENTITY();

Why would you need to waste memory using temp mem tables.
Ajit Ananthram
Ajit Ananthram
SSC Journeyman
SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)

Group: General Forum Members
Points: 75 Visits: 282
adam.everett (2/24/2011)
nice, good article never thought about how your could use vertical tables to solve that, and will also go and look at sequences in the next sql release!.

Can I ask why in the original code the lock on the kvp was required for the duration of the whole buniness transaction. Could they just not of got the required key values into some temps using some short transactions before the main long running business process transaction took place?


come to think about it, the kvp would not even need to be in a transaction if all they want is to increment a seed, a single update key statement to increment and at the same time assign the read value to a temp.

thanks;-)


Thanks for your feedback Adam, and yes, you are right! If only all application developers also knew this! One of the main reasons I decided to use the architecture using Identities was so that I could put in place a method for deriving KVP values which would be independent of long running transactions.

The procedures written in the article are cutdown versions of the real business procedures, which were much more lengthier. They also had conditions in them after which KVP values were derived, or completely skipped.

But I take your point, ideally, the derivation of KVP values should be done outside transactions.

Ajit Ananthram
Blog - http://ajitananthram.wordpress.com
vguruprasad_kpm
vguruprasad_kpm
SSC Rookie
SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)

Group: General Forum Members
Points: 25 Visits: 22
It opens up new way to solve the issue.

At the same time
There are two side-effect with this solution
1. We will end-up creating new table for each key.
2. There will be lot of dummy rows created, which needs to be cleaned periodically.
Ajit Ananthram
Ajit Ananthram
SSC Journeyman
SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)

Group: General Forum Members
Points: 75 Visits: 282
stephen.lear (2/24/2011)
Does your solution really solve the issue?

What if the requirement was for no gaps in the key sequence? Doesn't using identities in this way lead to gaps in the key sequence if a transaction is rolled back.

There is often a requirement to keep a continuous sequence, such as when assigning invoice numbers, in which case the original USP was correct, but your replacement may lead to gaps in sequence.


True, using Identities in transactions means a rollback of the transaction will not rollback the incremented value. For the application I was working with, this was not an issue at all. As long as the value obtained was unique, there was no problem. The goal of this exercise was to improve the concurrency in the database.

Ajit Ananthram
Blog - http://ajitananthram.wordpress.com
irozenberg
irozenberg
SSC Journeyman
SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)

Group: General Forum Members
Points: 86 Visits: 145
I agree, why Dynamic SQL AND Output?
What about SCOPE_IDENTITY function?

Cheers
Ajit Ananthram
Ajit Ananthram
SSC Journeyman
SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)

Group: General Forum Members
Points: 75 Visits: 282
irozenberg (2/24/2011)
I agree, why Dynamic SQL AND Output?
What about SCOPE_IDENTITY function?

Cheers


In the application, there wasn't just one key. There were a few, and there were plans to put in many more in the future. To cope with this, I wrote the dynamic sql so that the stored procedure could insert and fetch the values for any given key.

The naming convention I used for the tables was tbl_vert_<key>, where <key> would be replaced by the name of the KVP key.

Agreed the output clause could have been avoided with a call to scope_identity().

Ajit Ananthram
Blog - http://ajitananthram.wordpress.com
arturmariojr
arturmariojr
Grasshopper
Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)

Group: General Forum Members
Points: 10 Visits: 22
But now you will have as many tables as you have keys in original table and, for each increment on some key, you will add a new register in the key-table... if you have thousands of increments by day, you will have thousands of new registers and only the last one is neccessary.
May be the solution could be:
CREATE PROCEDURE [dbo].[USP_Get_Value_For_Key]
(
@key NVARCHAR(50),
@value INT OUTPUT
)
AS
BEGIN
[color=#550000]begin transaction[/color]
SELECT @value = 0
UPDATE tbl_kvp SET column_value += 1 WHERE column_key = @key
SELECT @value = column_value FROM tbl_kvp WHERE column_key = @key
[color=#550000]commit tran[/color]
END

The outer procedures don't need to implement the transaction for get the last id.
arty 15255
arty 15255
Valued Member
Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)Valued Member (61 reputation)

Group: General Forum Members
Points: 61 Visits: 77
arturmariojr (2/24/2011)
But now you will have as many tables as you have keys in original table and, for each increment on some key, you will add a new register in the key-table... if you have thousands of increments by day, you will have thousands of new registers and only the last one is neccessary.
May be the solution could be:
CREATE PROCEDURE [dbo].[USP_Get_Value_For_Key]
(
@key NVARCHAR(50),
@value INT OUTPUT
)
AS
BEGIN
[color=#550000]begin transaction[/color]
SELECT @value = 0
UPDATE tbl_kvp SET column_value += 1 WHERE column_key = @key
SELECT @value = column_value FROM tbl_kvp WHERE column_key = @key
[color=#550000]commit tran[/color]
END

The outer procedures don't need to implement the transaction for get the last id.


I like newbies Smile
You can always correct their sql statments Smile

...
UPDATE tbl_kvp SET
@value = column_value+1,
column_value = @value
WHERE column_key = @key
...

(that avoids need of "begin transaction")
arturmariojr
arturmariojr
Grasshopper
Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)

Group: General Forum Members
Points: 10 Visits: 22
Many thanks for correction -and they are always welcomed - but, if in the mean time you get the new value and goes to actually update the column, there no risk the database updates the column by other update command?
Artur
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search