Transactions and Locking

#11

I need it because I need each instance of my component to handle
different set of transactions, So if the first instance selected 50
transactions to handle, then it will lock them.using the SELECT
WITH(UPDLOCK, READPAST). But the second instance should not get the
same 50, so I used the READPAST to filter out those who already been
locked. Does this make since?

But I didn't understand why deadlocks may happen?

Regards,
Rami

Uri Dimant wrote:

Quote:

Rami
Why do you need READPAST hint? In very busy enviroment you can get DEADLOCK.
BOL says
READPAST
Skip locked rows. This option causes a transaction to skip rows locked by
other transactions that would ordinarily appear in the result set, rather
than block the transaction waiting for the other transactions to release
their locks on these rows. The READPAST lock hint applies only to
transactions operating at READ COMMITTED isolation and will read only past
row-level locks. Applies only to the SELECT statement.

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1169006809.536360.205140 (AT) q2g2000cwa (DOT) googlegroups.com...
One last question:

I updated your sample query in the following form:

DECLARE @ord INT
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
SELECT @ord=MAX(ORDER_ID) FROM Order WITH (UPDLOCK, READPAST)
UPDATE Order SET ORDER_STATUS= something WHERE (ORDER_ID = @ord)
COMMIT TRAN

The basic change here is that I removed the HOLDLOCK and put the
READPAST hint instead. I think the READPAST hint, will help in
filtering out those locked transactions. so each instance will see
unlocked transactiosns. But I removed HOLDLOCK because there was an
error generated if I included it with READPAST.

For me this seems to be working, is there any problem with this or any
hidden implications?

Thanks,
Rami

Uri Dimant wrote:
Rami
This seems to be a very interesting idea... But I want to clarify, this
means that one instance of the component will execute this select
statement and take the lock. Then the other instance may execute the
same statement again but get a failure because the rows are already
locked. So the second instance will be blocked from handling
transactions. Is this correct?

It does not block readers , it does block writers.

In my case I want each instance to select 100 rows for example and
process them completely before releasing them. But at the same time, I
want the other instance of the component to lock another 100 rows and
work on them exclusively.

Read about setting transaction isolation level in the BOL

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1168937506.272849.4080 (AT) 51g2000cwl (DOT) googlegroups.com...
Thanks again,

This seems to be a very interesting idea... But I want to clarify, this
means that one instance of the component will execute this select
statement and take the lock. Then the other instance may execute the
same statement again but get a failure because the rows are already
locked. So the second instance will be blocked from handling
transactions. Is this correct?

In my case I want each instance to select 100 rows for example and
process them completely before releasing them. But at the same time, I
want the other instance of the component to lock another 100 rows and
work on them exclusively.

Any help on this? and thanks a lot for your valuable answer.
Rami

Uri Dimant wrote:
Rami
You have to wrap the transactions with BEGIN TRAN ...COMMIT TRAN
make
sure that if you get a value an later on update it , use lockin hints
as
the below example
DECLARE @ord INT
BEGIN TRAN

SELECT @ord=MAX(OrderId) FROM Order WITH (UPDLOCK,HOLDLOCK)
UPDATE Table SET orderid =@ord WHERE.........

COMMIT TRAN

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1168917890.263676.286700 (AT) a75g2000cwd (DOT) googlegroups.com...
Thanks Uri,

Yes transactions do all opertaions like UPDATE/INSEERT/DELETE.
Tables
will be growing fast becuase these are payment transactions. Indexes
are defined on the columns used too much in WHERE clauses.

Uri Dimant wrote:
Rami
What do the queries do? Do the transactions UPDATE/INSEERT/DELETE
operation?
How big are the tables? Do you have indexes defined on the tables?

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1168859468.535588.297560 (AT) 51g2000cwl (DOT) googlegroups.com...
I have some requirement for an automated payment system. The
system
has
four machines setup as follows:
1- Two machines have a clustered database.
2- Two machines have a .net business logic component that will
handle
payment transactions with certain external component (Payment
Gateway)

My query is regarding transaction handling inside the business
logic
component. Because this component is running on two machines and
these
two instances of the component are accessing the same
transactions
table. I need these two components to work together without
blocking.
So transaction isolation level "Serialized" will not work with
this
model.

I am not clear about how to lock the specific rows that are being
handled by certain instance. If I set a flag (column) to lock the
row,
then that instance may fail before resetting the flag then this
row
will never be handled. In such a scenario I would expect the
other
instance to take over and handle whatever was locked previously
by
the
other instance.

Is there any ideas regarding arrangement between such components
which
access the same table?

Thanks a lot for the help,
Rami AlHasan

#12

Quote:

locked. Does this make since?
If it depends on your business requieremnts, it's OK

Quote:

But I didn't understand why deadlocks may happen?
Open more than three connection and run this script , well , in than

case you are going to get Primary Key Violation

--create table people (id int not null primary key, name char(1))

declare @id int
set @id=100
begin tran
if not exists (select * from people WITH ( updlock,readpast ) where id=@id )
begin
waitfor delay '00:00:30'
insert into people (id, name) values (@id ,'h')
end
commit tran

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote

Quote:

I need it because I need each instance of my component to handle
different set of transactions, So if the first instance selected 50
transactions to handle, then it will lock them.using the SELECT
WITH(UPDLOCK, READPAST). But the second instance should not get the
same 50, so I used the READPAST to filter out those who already been
locked. Does this make since?

But I didn't understand why deadlocks may happen?

Regards,
Rami

Uri Dimant wrote:
Rami
Why do you need READPAST hint? In very busy enviroment you can get
DEADLOCK.
BOL says
READPAST
Skip locked rows. This option causes a transaction to skip rows locked by
other transactions that would ordinarily appear in the result set, rather
than block the transaction waiting for the other transactions to release
their locks on these rows. The READPAST lock hint applies only to
transactions operating at READ COMMITTED isolation and will read only
past
row-level locks. Applies only to the SELECT statement.

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1169006809.536360.205140 (AT) q2g2000cwa (DOT) googlegroups.com...
One last question:

I updated your sample query in the following form:

DECLARE @ord INT
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
SELECT @ord=MAX(ORDER_ID) FROM Order WITH (UPDLOCK, READPAST)
UPDATE Order SET ORDER_STATUS= something WHERE (ORDER_ID = @ord)
COMMIT TRAN

The basic change here is that I removed the HOLDLOCK and put the
READPAST hint instead. I think the READPAST hint, will help in
filtering out those locked transactions. so each instance will see
unlocked transactiosns. But I removed HOLDLOCK because there was an
error generated if I included it with READPAST.

For me this seems to be working, is there any problem with this or any
hidden implications?

Thanks,
Rami

Uri Dimant wrote:
Rami
This seems to be a very interesting idea... But I want to clarify,
this
means that one instance of the component will execute this select
statement and take the lock. Then the other instance may execute the
same statement again but get a failure because the rows are already
locked. So the second instance will be blocked from handling
transactions. Is this correct?

It does not block readers , it does block writers.

In my case I want each instance to select 100 rows for example and
process them completely before releasing them. But at the same time,
I
want the other instance of the component to lock another 100 rows
and
work on them exclusively.

Read about setting transaction isolation level in the BOL

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1168937506.272849.4080 (AT) 51g2000cwl (DOT) googlegroups.com...
Thanks again,

This seems to be a very interesting idea... But I want to clarify,
this
means that one instance of the component will execute this select
statement and take the lock. Then the other instance may execute the
same statement again but get a failure because the rows are already
locked. So the second instance will be blocked from handling
transactions. Is this correct?

In my case I want each instance to select 100 rows for example and
process them completely before releasing them. But at the same time,
I
want the other instance of the component to lock another 100 rows
and
work on them exclusively.

Any help on this? and thanks a lot for your valuable answer.
Rami

Uri Dimant wrote:
Rami
You have to wrap the transactions with BEGIN TRAN ...COMMIT TRAN
make
sure that if you get a value an later on update it , use lockin
hints
as
the below example
DECLARE @ord INT
BEGIN TRAN

SELECT @ord=MAX(OrderId) FROM Order WITH (UPDLOCK,HOLDLOCK)
UPDATE Table SET orderid =@ord WHERE.........

COMMIT TRAN

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1168917890.263676.286700 (AT) a75g2000cwd (DOT) googlegroups.com...
Thanks Uri,

Yes transactions do all opertaions like UPDATE/INSEERT/DELETE.
Tables
will be growing fast becuase these are payment transactions.
Indexes
are defined on the columns used too much in WHERE clauses.

Uri Dimant wrote:
Rami
What do the queries do? Do the transactions
UPDATE/INSEERT/DELETE
operation?
How big are the tables? Do you have indexes defined on the
tables?

"Rami" <ramialhasan (AT) gmail (DOT) com> wrote in message
news:1168859468.535588.297560 (AT) 51g2000cwl (DOT) googlegroups.com...
I have some requirement for an automated payment system. The
system
has
four machines setup as follows:
1- Two machines have a clustered database.
2- Two machines have a .net business logic component that will
handle
payment transactions with certain external component (Payment
Gateway)

My query is regarding transaction handling inside the business
logic
component. Because this component is running on two machines
and
these
two instances of the component are accessing the same
transactions
table. I need these two components to work together without
blocking.
So transaction isolation level "Serialized" will not work with
this
model.

I am not clear about how to lock the specific rows that are
being
handled by certain instance. If I set a flag (column) to lock
the
row,
then that instance may fail before resetting the flag then
this
row
will never be handled. In such a scenario I would expect the
other
instance to take over and handle whatever was locked
previously
by
the
other instance.

Is there any ideas regarding arrangement between such
components
which
access the same table?

Thanks a lot for the help,
Rami AlHasan

#13

Rami wrote:

Quote:

I have some requirement for an automated payment system. The system has
four machines setup as follows:
1- Two machines have a clustered database.
2- Two machines have a .net business logic component that will handle
payment transactions with certain external component (Payment Gateway)

My query is regarding transaction handling inside the business logic
component. Because this component is running on two machines and these
two instances of the component are accessing the same transactions
table. I need these two components to work together without blocking.
So transaction isolation level "Serialized" will not work with this
model.

I am not clear about how to lock the specific rows that are being
handled by certain instance. If I set a flag (column) to lock the row,
then that instance may fail before resetting the flag then this row
will never be handled. In such a scenario I would expect the other
instance to take over and handle whatever was locked previously by the
other instance.

Is there any ideas regarding arrangement between such components which
access the same table?

Thanks a lot for the help,
Rami AlHasan

Sounds like a good scenario to use a service broker.

-----------------------
Alex Kuznetsov
http://sqlserver-tips.blogspot.com/
http://sqlserver-puzzles.blogspot.com/

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Transactions and Locking

Dotnet Distributed Applications microsoft.public.dotnet.distributed_apps

Re: Transactions and Locking - 01-17-2007 , 01:48 AM

Re: Transactions and Locking - 01-17-2007 , 05:02 AM

Re: Transactions and Locking - 01-17-2007 , 08:38 AM