Generar mi autonumerico

Hola Miguel,

On Fri, 23 May 2008 13:33:09 +0200, "Miguel Egea"
wrote:

Por otra parte, para cualquier neofito que lea este post no me gustaría que
se llevase la idea de que nivel serializable = bueno o adecuado

Hombre, el nivel de aislamiento serializable es el bueno, otra cosa es
que por culpa del obsoleto sistema de control de concurrencia de SQL
Server haya que hacer la chapuza de utilizar niveles de concurrencia
defectuosos en algunos casos.

<Miguel Egea>
No, no es cierto, el ejemplo que le he puesto a alfredo lo demuestra, además
no son phantom read, una lectura fantasma solo se puede producir en el nivel
de aislamiento read uncommited, equivocas el concepto.
</Miguel Egea>

Parece que estás confundiendo las filas fantasma con las lecturas
sucias. Las filas fantasma se pueden dar con niveles inferiores a
SNAPSHOT, es decir con READ UNCOMMITTED, READ COMMITTED y REPEATABLE
READ.


Saludos
Alfredo

Hola Miguel,

On Fri, 23 May 2008 13:36:31 +0200, "Miguel Egea"
wrote:

El select max() en otros niveles de aislamiento dará error por Pk, un error
de pk violada es menos agresivo que un deadlock, por que un deadlock además
mata la conexión del elegido como víctima,

Pues menuda castaña, entonces si que es preferible que te salga un
error por PK.

Un error por interbloqueo debería de resolverse de forma que no se
enterasen las aplicaciones.


Saludos
Alfredo

Así es, por eso la complejidad del procedure que mandé :)


De todas formas me confuncí en el post, leí lecturas sucias en lugar de
lecturas fantasmas :( mis disculpas.



"Alfredo Novoa" wrote in message
news:

Hola Miguel,

On Fri, 23 May 2008 13:36:31 +0200, "Miguel Egea"
wrote:

El select max() en otros niveles de aislamiento dará error por Pk, un
error
de pk violada es menos agresivo que un deadlock, por que un deadlock
además
mata la conexión del elegido como víctima,

Pues menuda castaña, entonces si que es preferible que te salga un
error por PK.

Un error por interbloqueo debería de resolverse de forma que no se
enterasen las aplicaciones.


Saludos
Alfredo

Es cierto que hablaba de lecturas sucias y no fantasma, leí mal tu mensaje,
mis disculpas.

Que sistema de control de concurrencia que sea obsoleto es una opinión, que
como tuya respeto, pero no comparto.

Es cierto que otros gestores manejan de otra forma la concurrencia, de ahí
la aparición en 2005 de los niveles de aislamiento snapshot. que aportan
sabores parecidos a lo que hacen otros gestores en los que lectores no
bloquean escritores, aún así, serializable no es un nivel SQL Server sino un
nivel ISO aunque obviamente la implementación es microsoft.

En cualquier caso creo que queda claro del hilo que el nivel de aislamiento
serializable por defecto no es, por regla general, una buena idea en SQL
Server si se pretenden hacer aplicaciones escalables.

Saludos
Miguel Egea


"Alfredo Novoa" wrote in message
news:

Hola Miguel,

On Fri, 23 May 2008 13:33:09 +0200, "Miguel Egea"
wrote:

Por otra parte, para cualquier neofito que lea este post no me gustaría
que
se llevase la idea de que nivel serializable = bueno o adecuado

Hombre, el nivel de aislamiento serializable es el bueno, otra cosa es
que por culpa del obsoleto sistema de control de concurrencia de SQL
Server haya que hacer la chapuza de utilizar niveles de concurrencia
defectuosos en algunos casos.

<Miguel Egea>
No, no es cierto, el ejemplo que le he puesto a alfredo lo demuestra,
además
no son phantom read, una lectura fantasma solo se puede producir en el
nivel
de aislamiento read uncommited, equivocas el concepto.
</Miguel Egea>

Parece que estás confundiendo las filas fantasma con las lecturas
sucias. Las filas fantasma se pueden dar con niveles inferiores a
SNAPSHOT, es decir con READ UNCOMMITTED, READ COMMITTED y REPEATABLE
READ.


Saludos
Alfredo

Hola Miguel,

Vaya! Me voy a una reunión de dos horitas y esto ya ha explotado :)

Solo un par de reacciones que veo que ya se han aclarado muchas
cosas.


On May 23, 1:33 pm, "Miguel Egea" wrote:

Hola Carlos, no suelo comentar cada párrafo de los que me dicen, creo que se
hace dificil de leer, pero como es una opinión personal y tu lo has hecho te
contesto de la misma forma :-). Respetuosamente y siempre hablando desde el
punto de vista técnico estás en un error, espero que te ayude a aclararlo.

He vuelto a leer mi reacción y no veo nada opinable en ella.
Los conceptos de 'serializabilidad de transacciones' y de
lo que es un 'phantom read' los tengo muy claros :-)

Manejo bases de datos con miles de usuarios concurrentes, y en estos
escenarios el nivel de aislamiento serializables es inviable, simplemente
inviable.

Aquí si que tengo la tendencia a creerte.
Vamos... que estoy 'casi seguro' de que es así como dices;
pero ese es el problema de SQL Server y no de conceptos.

Saludos,
Carlos