February 23, 2011 at 9:55 pm
Comments posted to this topic are about the item Use of Identity Property to Resolve Concurrency Issues
Ajit Ananthram
Blog - http://ajitananthram.wordpress.com
February 23, 2011 at 11:43 pm
Removed the rude coment. I am sorry.
Microsoft MVP 2006-2010
February 24, 2011 at 2:00 am
And your reply teaches us that you are ill-mannered and rude.
Good article, Ajit. Very well written, clear and concise.
February 24, 2011 at 2:03 am
You are right, I appologize.
I am really sorry - I let my own problems take over.
Microsoft MVP 2006-2010
February 24, 2011 at 2:14 am
I'm not sure that setting the seed to the next number in logical order is the right way, Personally I would be setting the seed to start from a number somewhat larger than the current, simply to avoid the chance of collisions.
In your example rather than setting the seed to Current+1 I would be inclined to set it to 100 (or some other factor of 10 depending on the current position), this way I could easily Identify the rows that were assigned by the new method and track any issues that were being created.
As you state in the article,the introduction of Denali solves this type of problem with the new SEQUENCE statement.
_________________________________________________________________________
SSC Guide to Posting and Best Practices
February 24, 2011 at 2:18 am
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;-)
February 24, 2011 at 3:04 am
Just my thought on this article...
Why do we need a begin transaction statement at the start of the procedure USP_Business_Process. Everytime the sub-procedure : USP_Get_Value_For_Key is called, it will always have a unique value.
So, the statement : BEGIN TRANSACTION Business_Process, should be after the call to the procedure USP_Get_Value_For_Key.
i.e after the statement : SELECT @val -- Print key value for display,
in the procedure: USP_Business_Process.
This way there will be no blocking issue for the table: tbl_kvp
Haven't tested this but think this should work.
February 24, 2011 at 3:05 am
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.
February 24, 2011 at 3:07 am
May i know how it will help while updating the records. (ie. multiple users updating same record from the different sessions). As per your message, it will allow multiple users to update the same record.
February 24, 2011 at 3:32 am
Why use the output syntax, table variable and dynamic sql?
Wouldn't the following be simpler (no permissions issue on table if user running it only has access to SP either) :
insert into ...
set @outputId = scope_identity()
February 24, 2011 at 3:36 am
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.
February 24, 2011 at 3:42 am
I also use SCOPE_IDENTITY();
Why would you need to waste memory using temp mem tables.
February 24, 2011 at 4:13 am
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
February 24, 2011 at 4:23 am
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.
February 24, 2011 at 4:32 am
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
Viewing 15 posts - 1 through 15 (of 63 total)
You must be logged in to reply to this topic. Login to reply