UPDATE con WITH ROWLOCK

Isaias,

Por que encierras esa sentencia en una transaccion explicita?
Por que usas ROWCOUNT?

De todas maneras te comento que el deadlock se debe a que los objetos estan
sientdo accesidos en diferente orden. Yo primero localizaria que
procedimientos y/o objetos estan participando en el deadlock y trataria de
corregirlos.

INF: Analyzing and Avoiding Deadlocks in SQL Server
http://support.microsoft.com/defaul...-us;169960

Tracing Deadlocks
http://www.sqlservercentral.com/col...dlocks.asp


AMB

"Isaias" wrote:

Estoy teniendo problemas de registros agarrados (Dead_Lock) con el siguiente
panorama, 20 usuarios conectados simultanemente, van a una tabla y TOMAN un
registros, de la siguiente forma:

BEGIN TRAN Asigna_Registro
SET ROWCOUNT 1
UPDATE MyTabla SET Status = 2, Empleado = @Empleado WHERE Campaña =
@Campaña AND Status = 1
SET ROWCOUNT 0
COMMIT TRAN Asigna_Registro



Para solventar el problema estaba pensando agregar en la clausula de UPDATE

UPDATE MyTabla (WITH ROWLOCK)

Me gustaria leer comentarios sobre mi posible solucion al problema.

Saludos
IIslas

Gracias por tu comentario, te doy mis respuestas

Por que encierras esa sentencia en una transaccion explicita?
R= Porque queria evitar el DEAD_LOCK, o al menos eso creia

Por que usas ROWCOUNT?
R= Porque cada usuario debe tomar SOLO UN REGISTRO y cuando digo, tomarlo,
es que le estoy cambiando el STATUS al registro, lo cambio de un status 1 a
un status 2.

Mas adelante, en el mismo store, le regreso al aplicativo (ASP), el registro
con un:

SELECT TOP 1 * FROM MyTabla WHERE Campaña = @Campaña AND Empleado =
@Empleado AND Status = 2

Es el UNICO store que ejecutan mis clientes (usuarios), solo que me empezo a
dar DEAD_LOCK a partir de que comparti mi servidor (un arreglo de discos) con
otro sistema que guarda BUZONES de voz.

SQL Server me ha tomado el TOTAL DE LA MEMORIA y precisamente cuando se
estan guardando los buzones de voz (*.wav), es cuando sucede el problema, en
realidad, NO HAY DEAD LOCK, simplemente, hay 2 usuarios que tienen asignado
el MISMO REGISTRO.

Espero haberme explicado.



Saludos
IIslas


"Alejandro Mesa" escribió:

Isaias,

Por que encierras esa sentencia en una transaccion explicita?
Por que usas ROWCOUNT?

De todas maneras te comento que el deadlock se debe a que los objetos estan
sientdo accesidos en diferente orden. Yo primero localizaria que
procedimientos y/o objetos estan participando en el deadlock y trataria de
corregirlos.

INF: Analyzing and Avoiding Deadlocks in SQL Server
http://support.microsoft.com/defaul...-us;169960

Tracing Deadlocks
http://www.sqlservercentral.com/col...dlocks.asp


AMB

"Isaias" wrote:

> Estoy teniendo problemas de registros agarrados (Dead_Lock) con el siguiente
> panorama, 20 usuarios conectados simultanemente, van a una tabla y TOMAN un
> registros, de la siguiente forma:
>
> BEGIN TRAN Asigna_Registro
> SET ROWCOUNT 1
> UPDATE MyTabla SET Status = 2, Empleado = @Empleado WHERE Campaña =
> @Campaña AND Status = 1
> SET ROWCOUNT 0
> COMMIT TRAN Asigna_Registro
>
>
>
> Para solventar el problema estaba pensando agregar en la clausula de UPDATE
>
> UPDATE MyTabla (WITH ROWLOCK)
>
> Me gustaria leer comentarios sobre mi posible solucion al problema.
>
> Saludos
> IIslas

Isaias,

Puedes tratar:

declare @pk int

begin transaction

select @pk = pk
from t1 with (UPDLOCK)
where Campaña = @Campaña AND Empleado = @Empleado AND Status = 1

if @pk is not null
update t1
set status = 2
where Campaña = @Campaña AND Empleado = @Empleado AND Status = 1

commit transaction

En cuanto a devolver la fila a la aplicacion, usa la clave primaria en vez
de "top 1".


AMB

"Isaias" wrote:

Gracias por tu comentario, te doy mis respuestas

Por que encierras esa sentencia en una transaccion explicita?
R= Porque queria evitar el DEAD_LOCK, o al menos eso creia

Por que usas ROWCOUNT?
R= Porque cada usuario debe tomar SOLO UN REGISTRO y cuando digo, tomarlo,
es que le estoy cambiando el STATUS al registro, lo cambio de un status 1 a
un status 2.

Mas adelante, en el mismo store, le regreso al aplicativo (ASP), el registro
con un:

SELECT TOP 1 * FROM MyTabla WHERE Campaña = @Campaña AND Empleado =
@Empleado AND Status = 2

Es el UNICO store que ejecutan mis clientes (usuarios), solo que me empezo a
dar DEAD_LOCK a partir de que comparti mi servidor (un arreglo de discos) con
otro sistema que guarda BUZONES de voz.

SQL Server me ha tomado el TOTAL DE LA MEMORIA y precisamente cuando se
estan guardando los buzones de voz (*.wav), es cuando sucede el problema, en
realidad, NO HAY DEAD LOCK, simplemente, hay 2 usuarios que tienen asignado
el MISMO REGISTRO.

Espero haberme explicado.



Saludos
IIslas


"Alejandro Mesa" escribió:

> Isaias,
>
> Por que encierras esa sentencia en una transaccion explicita?
> Por que usas ROWCOUNT?
>
> De todas maneras te comento que el deadlock se debe a que los objetos estan
> sientdo accesidos en diferente orden. Yo primero localizaria que
> procedimientos y/o objetos estan participando en el deadlock y trataria de
> corregirlos.
>
> INF: Analyzing and Avoiding Deadlocks in SQL Server
> http://support.microsoft.com/defaul...-us;169960
>
> Tracing Deadlocks
> http://www.sqlservercentral.com/col...dlocks.asp
>
>
> AMB
>
> "Isaias" wrote:
>
> > Estoy teniendo problemas de registros agarrados (Dead_Lock) con el siguiente
> > panorama, 20 usuarios conectados simultanemente, van a una tabla y TOMAN un
> > registros, de la siguiente forma:
> >
> > BEGIN TRAN Asigna_Registro
> > SET ROWCOUNT 1
> > UPDATE MyTabla SET Status = 2, Empleado = @Empleado WHERE Campaña =
> > @Campaña AND Status = 1
> > SET ROWCOUNT 0
> > COMMIT TRAN Asigna_Registro
> >
> >
> >
> > Para solventar el problema estaba pensando agregar en la clausula de UPDATE
> >
> > UPDATE MyTabla (WITH ROWLOCK)
> >
> > Me gustaria leer comentarios sobre mi posible solucion al problema.
> >
> > Saludos
> > IIslas

Hola creo que en el update deberías usar también la clave primaria, de todas
formas ¿esa transacción explicita está anidada? es decir cuanto vale ahí en
medio select @@trancount lo digo por que una única instrución update
provocando un deadlock no me cuadra, incluso si el bloqueo se ha elevado a
página por problemas de memoria.

Saludos cordiales
Miguel Egea

"Alejandro Mesa" escribió en el
mensaje news:

Isaias,

Puedes tratar:

declare @pk int

begin transaction

select @pk = pk
from t1 with (UPDLOCK)
where Campaña = @Campaña AND Empleado = @Empleado AND Status = 1

if @pk is not null
update t1
set status = 2
where Campaña = @Campaña AND Empleado = @Empleado AND Status = 1

commit transaction

En cuanto a devolver la fila a la aplicacion, usa la clave primaria en vez
de "top 1".


AMB

"Isaias" wrote:

Gracias por tu comentario, te doy mis respuestas

Por que encierras esa sentencia en una transaccion explicita?
R= Porque queria evitar el DEAD_LOCK, o al menos eso creia

Por que usas ROWCOUNT?
R= Porque cada usuario debe tomar SOLO UN REGISTRO y cuando digo,
tomarlo,
es que le estoy cambiando el STATUS al registro, lo cambio de un status 1
a
un status 2.

Mas adelante, en el mismo store, le regreso al aplicativo (ASP), el
registro
con un:

SELECT TOP 1 * FROM MyTabla WHERE Campaña = @Campaña AND Empleado >> @Empleado AND Status = 2

Es el UNICO store que ejecutan mis clientes (usuarios), solo que me
empezo a
dar DEAD_LOCK a partir de que comparti mi servidor (un arreglo de discos)
con
otro sistema que guarda BUZONES de voz.

SQL Server me ha tomado el TOTAL DE LA MEMORIA y precisamente cuando se
estan guardando los buzones de voz (*.wav), es cuando sucede el problema,
en
realidad, NO HAY DEAD LOCK, simplemente, hay 2 usuarios que tienen
asignado
el MISMO REGISTRO.

Espero haberme explicado.



Saludos
IIslas


"Alejandro Mesa" escribió:

> Isaias,
>
> Por que encierras esa sentencia en una transaccion explicita?
> Por que usas ROWCOUNT?
>
> De todas maneras te comento que el deadlock se debe a que los objetos
> estan
> sientdo accesidos en diferente orden. Yo primero localizaria que
> procedimientos y/o objetos estan participando en el deadlock y trataria
> de
> corregirlos.
>
> INF: Analyzing and Avoiding Deadlocks in SQL Server
> http://support.microsoft.com/defaul...-us;169960
>
> Tracing Deadlocks
> http://www.sqlservercentral.com/col...dlocks.asp
>
>
> AMB
>
> "Isaias" wrote:
>
> > Estoy teniendo problemas de registros agarrados (Dead_Lock) con el
> > siguiente
> > panorama, 20 usuarios conectados simultanemente, van a una tabla y
> > TOMAN un
> > registros, de la siguiente forma:
> >
> > BEGIN TRAN Asigna_Registro
> > SET ROWCOUNT 1
> > UPDATE MyTabla SET Status = 2, Empleado = @Empleado WHERE Campaña
> > >> > > @Campaña AND Status = 1
> > SET ROWCOUNT 0
> > COMMIT TRAN Asigna_Registro
> >
> >
> >
> > Para solventar el problema estaba pensando agregar en la clausula de
> > UPDATE
> >
> > UPDATE MyTabla (WITH ROWLOCK)
> >
> > Me gustaria leer comentarios sobre mi posible solucion al problema.
> >
> > Saludos
> > IIslas

Gracias

He substituido el UPDLOCK por el XLOC, ya que con UPDLOCK, si me dejaba
hacer lecturas y precisamente eso es lo que no queria.

Mucha gracias por sus comentarios.
Saludos
IIslas


"Miguel Egea" escribió:

Hola creo que en el update deberías usar también la clave primaria, de todas
formas ¿esa transacción explicita está anidada? es decir cuanto vale ahí en
medio select @@trancount lo digo por que una única instrución update
provocando un deadlock no me cuadra, incluso si el bloqueo se ha elevado a
página por problemas de memoria.

Saludos cordiales
Miguel Egea

"Alejandro Mesa" escribió en el
mensaje news:
> Isaias,
>
> Puedes tratar:
>
> declare @pk int
>
> begin transaction
>
> select @pk = pk
> from t1 with (UPDLOCK)
> where Campaña = @Campaña AND Empleado = @Empleado AND Status = 1
>
> if @pk is not null
> update t1
> set status = 2
> where Campaña = @Campaña AND Empleado = @Empleado AND Status = 1
>
> commit transaction
>
> En cuanto a devolver la fila a la aplicacion, usa la clave primaria en vez
> de "top 1".
>
>
> AMB
>
> "Isaias" wrote:
>
>> Gracias por tu comentario, te doy mis respuestas
>>
>> Por que encierras esa sentencia en una transaccion explicita?
>> R= Porque queria evitar el DEAD_LOCK, o al menos eso creia
>>
>> Por que usas ROWCOUNT?
>> R= Porque cada usuario debe tomar SOLO UN REGISTRO y cuando digo,
>> tomarlo,
>> es que le estoy cambiando el STATUS al registro, lo cambio de un status 1
>> a
>> un status 2.
>>
>> Mas adelante, en el mismo store, le regreso al aplicativo (ASP), el
>> registro
>> con un:
>>
>> SELECT TOP 1 * FROM MyTabla WHERE Campaña = @Campaña AND Empleado > >> @Empleado AND Status = 2
>>
>> Es el UNICO store que ejecutan mis clientes (usuarios), solo que me
>> empezo a
>> dar DEAD_LOCK a partir de que comparti mi servidor (un arreglo de discos)
>> con
>> otro sistema que guarda BUZONES de voz.
>>
>> SQL Server me ha tomado el TOTAL DE LA MEMORIA y precisamente cuando se
>> estan guardando los buzones de voz (*.wav), es cuando sucede el problema,
>> en
>> realidad, NO HAY DEAD LOCK, simplemente, hay 2 usuarios que tienen
>> asignado
>> el MISMO REGISTRO.
>>
>> Espero haberme explicado.
>>
>>
>>
>> Saludos
>> IIslas
>>
>>
>> "Alejandro Mesa" escribió:
>>
>> > Isaias,
>> >
>> > Por que encierras esa sentencia en una transaccion explicita?
>> > Por que usas ROWCOUNT?
>> >
>> > De todas maneras te comento que el deadlock se debe a que los objetos
>> > estan
>> > sientdo accesidos en diferente orden. Yo primero localizaria que
>> > procedimientos y/o objetos estan participando en el deadlock y trataria
>> > de
>> > corregirlos.
>> >
>> > INF: Analyzing and Avoiding Deadlocks in SQL Server
>> > http://support.microsoft.com/defaul...-us;169960
>> >
>> > Tracing Deadlocks
>> > http://www.sqlservercentral.com/col...dlocks.asp
>> >
>> >
>> > AMB
>> >
>> > "Isaias" wrote:
>> >
>> > > Estoy teniendo problemas de registros agarrados (Dead_Lock) con el
>> > > siguiente
>> > > panorama, 20 usuarios conectados simultanemente, van a una tabla y
>> > > TOMAN un
>> > > registros, de la siguiente forma:
>> > >
>> > > BEGIN TRAN Asigna_Registro
>> > > SET ROWCOUNT 1
>> > > UPDATE MyTabla SET Status = 2, Empleado = @Empleado WHERE Campaña
>> > > > >> > > @Campaña AND Status = 1
>> > > SET ROWCOUNT 0
>> > > COMMIT TRAN Asigna_Registro
>> > >
>> > >
>> > >
>> > > Para solventar el problema estaba pensando agregar en la clausula de
>> > > UPDATE
>> > >
>> > > UPDATE MyTabla (WITH ROWLOCK)
>> > >
>> > > Me gustaria leer comentarios sobre mi posible solucion al problema.
>> > >
>> > > Saludos
>> > > IIslas