Sobre accesos concurrentes.

04/07/2003 - 09:37 por Tako | Informe spam
Hola gente.

Estamos en pleno análisis de una aplicación y estamos planteándonos el
tema de que varios usuarios intenten modificar el mismo elemento a la par,
si se deja tal y como esta es evidente que el último que haga los cambios se
llevara el pato al agua, pero claro, modificara los datos que ha cambiado el
primero.

Así que estamos pensando en como evitar esto, salen propuestas de llevar
un registro de bloqueos de forma que no se pueda modificar ciertos datos si
alguien ya los esta modificando... etc.

La cuestión es si alguien sabe si hay algún forma estándar de manejar
esto o al menos algunos guías que documenten esto, o quizás el nuevo ADO.NET
lleve algo relacionado con esto, al fin y al cabo me parece una situación
muy común.

Bueno, si alguien sabe algo de esto o quiere contarme sus experiencias
relacionadas con este tema estaré encantado.

Muchas gracias de antemano.

Preguntas similare

Leer las respuestas

#1 C.J.Ríos
07/07/2003 - 17:18 | Informe spam
Hola a

Ese problema lo puedes evitar 'automáticamente' abriendo las conexiones a
las bases de datos
en modo pesimista. De esta forma el servidor de datos bloquea cualquier
acceso sobre datos que se están usando por otro usuario.

Esto tiene como desventaja que ralentiza el acceso a los datos, ya que para
la lectura de los datos, si suponemos que siempre habrá 2 ó más usuarios
accediendo a ellos, es servidor mantendrá a la espera innecesariamente a uno
de ellos.

Lo propio es jugar a abrir las conexiones en modo optimista o pesimista
según convenga: Si los datos son principalmente de lectura --> optimista. Si
por regla general son de lectura/escritura >pesimista.

Espero que sirva de ayuda.

Salu2.

"Tako" escribió en el mensaje
news:

Hola gente.

Estamos en pleno análisis de una aplicación y estamos planteándonos el
tema de que varios usuarios intenten modificar el mismo elemento a la par,
si se deja tal y como esta es evidente que el último que haga los cambios


se
llevara el pato al agua, pero claro, modificara los datos que ha cambiado


el
primero.

Así que estamos pensando en como evitar esto, salen propuestas de


llevar
un registro de bloqueos de forma que no se pueda modificar ciertos datos


si
alguien ya los esta modificando... etc.

La cuestión es si alguien sabe si hay algún forma estándar de manejar
esto o al menos algunos guías que documenten esto, o quizás el nuevo


ADO.NET
lleve algo relacionado con esto, al fin y al cabo me parece una situación
muy común.

Bueno, si alguien sabe algo de esto o quiere contarme sus experiencias
relacionadas con este tema estaré encantado.

Muchas gracias de antemano.


Respuesta Responder a este mensaje
#2 Tako
08/07/2003 - 08:38 | Informe spam
Gracias por la idea, pero la pregunta iba por métodos para hacer
bloqueos desconectado, no conectado, de forma que si te han cambiado los
datos mientras tu veías la pantalla se pueda avisar al usuario y no dejarle
grabar sin ver los datos actualizados.

"C.J.Ríos" wrote in message
news:JagOa.463937$
Hola a

Ese problema lo puedes evitar 'automáticamente' abriendo las conexiones a
las bases de datos
en modo pesimista. De esta forma el servidor de datos bloquea cualquier
acceso sobre datos que se están usando por otro usuario.

Esto tiene como desventaja que ralentiza el acceso a los datos, ya que


para
la lectura de los datos, si suponemos que siempre habrá 2 ó más usuarios
accediendo a ellos, es servidor mantendrá a la espera innecesariamente a


uno
de ellos.

Lo propio es jugar a abrir las conexiones en modo optimista o pesimista
según convenga: Si los datos son principalmente de lectura --> optimista.


Si
por regla general son de lectura/escritura >pesimista.

Espero que sirva de ayuda.

Salu2.

"Tako" escribió en el mensaje
news:
>
> Hola gente.
>
> Estamos en pleno análisis de una aplicación y estamos planteándonos


el
> tema de que varios usuarios intenten modificar el mismo elemento a la


par,
> si se deja tal y como esta es evidente que el último que haga los


cambios
se
> llevara el pato al agua, pero claro, modificara los datos que ha


cambiado
el
> primero.
>
> Así que estamos pensando en como evitar esto, salen propuestas de
llevar
> un registro de bloqueos de forma que no se pueda modificar ciertos datos
si
> alguien ya los esta modificando... etc.
>
> La cuestión es si alguien sabe si hay algún forma estándar de


manejar
> esto o al menos algunos guías que documenten esto, o quizás el nuevo
ADO.NET
> lleve algo relacionado con esto, al fin y al cabo me parece una


situación
> muy común.
>
> Bueno, si alguien sabe algo de esto o quiere contarme sus


experiencias
> relacionadas con este tema estaré encantado.
>
> Muchas gracias de antemano.
>
>


Respuesta Responder a este mensaje
#3 Tako
08/07/2003 - 11:30 | Informe spam
Pues ahora con ADO.NET la forma "recomendada" es comparar a la hora de
hacer el update los campos originales con los campos de la base de datos y
si son diferentes te avisan, de echo hasta el Visual Studio te puede generar
los store procedures para trabajar así.

"danicastillo" wrote in message
news:

No se si existe forma estandar, pero supongo que quieres algo "que


funcione"
=)

Una forma es :cuando abres el formulario con los datos, incluyes un campo
oculto con la fecha y hora de "visualizacion", en cada tabla incluyes un
campo con "fechaultimamodificacion", cuando tiras a grabar un formulario,


si
fechavisualizacion<fechaultimamodificacion lanza un aviso de ver los datos
antiguos etc, sino , simplemente grabas y marcas la nueva fecha de
modificacion

Respuesta Responder a este mensaje
#4 SqlRanger
16/07/2003 - 10:24 | Informe spam
Yo tengo un componente: el SqlRanger.SqlAdapter que te permite gestionar de
forma automática los confictos de concurrencia de todas las formas posibles
estableciendo ciertas propiedades:

http://sqlranger.com/Descargas.aspx




Saludos:

Jesús López
MVP Microsoft .NET
MCP SQL Server
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida