Transacciones Concurrentes

[[gluglu]]

Hola a todos !

Cómo tengo que definir dos transacciones diferentes para que una vea los cambios de la otra aun sin haber hecho un Commit ?

Con Read_Committed, como su propio nombre indica, no puedo leer en una transacción los cambios que realiza otra hasta que no se aplica el Commit.

Se trata de Reservas de Habitaciones en mi aplicación de reservas de hoteles. Si un usuario elige un número de habitación, inmediatamente tiene que aparecer que esa habitación está ocupada para los demás usuarios. Pero lo que quiero permitir es que el primer usuario pueda hacer un Rollback para volver a dejar las habitaciones libres que NO ha confirmado con Commit, en caso de que finalmente no confirme la operación.

Supongo que el mismo caso se daría con una aplicación bancaria. Si alguien intenta sacar dinero de un cajero, para todos los demás tiene que aparecer como reducido de su saldo, para que no pueda haber extracciones simultáneas en dos cajeros diferentes. Pero si finalmente el usuario decide cancelar la operación, todo volverá a su estado original.

Gracias por vuestra ayuda

[[Caral]]

Hola gluglu
Supongo que debe haber una determinada cantidad de habiaciones
Yo haria una tabla con todas las habitaciones y que cada vez que se trate de reservar una habitacion, se indique un si o no.
De esta manera cuando empiece el programa leera primero esta tabla y podra definir si esta o no reservada, esto lo haria con un timer con poco tiempo asi siempre se estaria actualizando.
Saludos

[[gluglu]]

Gracias Caral por responder.

Pero no es así como tengo planteada la aplicación.

Sé que se puede hacer lo que yo pretendo con transacciones. Pero quiero evitar el commit de una para que la otra me pueda leer.

Creo haber leido sobre el tema, pero no me acuerdo. He buscado también ya en el foro pero no encuentro la respuesta correcta. Por eso acudo a vuestra ayuda.

[[ArdiIIa]]

Empezado por gluglu

Creo haber leido sobre el tema, pero no me acuerdo. He buscado también ya en el foro pero no encuentro la respuesta correcta. Por eso acudo a vuestra ayuda.

A lo mejor esto te aclara algo...

[[egostar]]

Este tema implica varias cosas.

• Necesitas saber si se va a reservar por habitación o por tipo de habitación.
• Necesitas una tabla de reservas donde indiques [tipo] o [numero] de habitación, fecha de ingreso y noches reservadas.
• Si la reserva es con garantía o sin garantía, eso es muy importante.
• Si es con un paquete o plan

En fin, yo no creo que necesites dos transacciones, tu generas la reserva y se debe actualizar en todos las aplicaciones cliente, la reserva debería de permanecer hasta que es cancelada por el cliente que la solicitó, o con un limite de tiempo si no está garantizada, si está garantizada no hay problema porque si no se presenta el huesped, se genera lo que se llama "No Show".

En fin, tiene su complejidad esto de las reservaciones.

Salud OS.

[[Caral]]

Bueno
Aqui trabajo con piezas y estas pueden ser apartadas por cualquier cliente o directamente por la empresa.
Lo que hago es crear una tabla en donde pongo la pieza reservada, asi la quito del inventario y no la puede apartar otro cliente.
Tengo 8 clientes por internet y dos personas aqui, nunca he tenido un problema con los apartados.
Me parece que esto del Commit trae mas complicaciones porque depende en mucho de la maquina y la base de datos, asi como del tiempo en el que se haga la transferencia.
No se es nada mas una opinion.
Saludos

[Mick]

No se si entiendo bien, pero eso de las reservas, implica que la transaccion no se confirmaria durante horas o dias, y eso no se puede hacer.

Entre el inicio de una transaccion y su commit o rollback, no deben pasar mas de unos pocos milisegundos o decimas de segundo.

El sistema de transacciones no esta pensado para hacerlas de horas o dias, si la aplicacion pierde la conexion con la base de datos, las transacciones en curso se cancelan, se hace un rollback automatico. Asi que si se te apaga el servidor o un cliente se queda sin red perderias todas las reservas pendintes de los clientes.

En cuanto al tema del banco, no se trabaja asi, el cliente hace lo que tenga que hacer, y solo en el ultimo milisegundo, cuando pulsas el boton aceptar, se comienza la transaccion , se hace lo que sea y lo mas rapidamente posible, en cosa de decimas de segundo o segundos a lo sumo , se confirma (o se cancela si hay algun problema).
Que pasa si coinciden dos operaciones en el mismo momento sobre la misma cuenta bancaria (sobre el mismo registro de la base de datos) ??, pues que en el mismo momento no es posible que se den, a lo sumo una puede entrar unos nanosegundos o milisegundos mas tarde que otra, pues simplemente la que entre mas tarde ESPERA a que finalize la primera transaccion (que se haga commit o rollback), que sera normalmente cosa de decimas de segundo como mucho y despues se realiza la segunda. Esto precisamente es lo que garantiza que el saldo sea coherente.
Normalmente a mayores hay un timeout, si una transaccion tiene que esperar a que finalize otra mas de X segundos, pues se aborta la transaccion y se da un error al usuario indicando que no se puede realizar la operacion solicitada, o se espera un poco y se reintenta.

Imaginate que usasen los bancos un sistema como el que pretendes, imaginate que se te queda tonto el ordenador del cajero cuando esta atendiendo a un cliente, y todo el resto de operaciones de entrada o salida de dinero sobre esa cuenta tuviesen que quedar ahi esperando horas o dias a que reparasen el cajero .

En definitiva creo que estas enfocando mal el problema.

Yo creo que lo mas sencillo es que escribas simplemente en una tabla que tal cliente o tal puesto, tiene seleccionada tal habitacion por x segundos o x minutos o x horas. Para ello apuntas la habitacion, quien la tiene seleccionada y la fecha/hora en la que caducara esta seleccion.
De este modo queda bloqueada la habitacion durante ese tiempo como mucho, el resto de puestos podran leerla pero no podran Selecionarla debido a que ven que esta seleccionada por otro puesto y que esta seleccion aun no ha caducado (aun no ha llegado la hora de caducidad).
Esto funciona incluso aunque se bloquee uno de lospuestos de gestion, ya que se desbloquearia automaticamente la habitacion en cuanto llegase la fecha/hora fijada.

Un Saludo

[roman]

Según yo entiendo, hay aquí una confusión con el término "confirmación".

Por un lado está la confirmación que un cliente puede hacer de las reservaciones que haya hecho previamente. Esto es, hoy reservo tres habitaciones y pasado mañana confirmo la reservación. En ese caso, aplica lo dicho por egostar y Mick.

Pero, por otro lado, está la confirmación de la operación al momento de reservar. Es decir, yo entro al sistema, digo que quiero reservar tres habitaciones y oprimo el botón Aceptar (commit) o Cancelar (rollback), es decir, confirmo que reservo las habitaciones. Me parece que es a esto último a lo que se refiere gluglu.

En todo caso, aplica lo que comenta Mick, la transacción debe durar lo menos posible.

Lo que yo hago en una situación similar- que no igual, pues nada tiene que ver con reservaciones -es:

1. Muestro al cliente el número de habitaciones disponibles
2. El cliente escoge cuántas habitaciones reserva.
3. El cliente oprime Aceptar
4. Inicio una transacción
5. Resto al número de habitaciones disponibles el número solicitado.
6. Consulto el número de habitaciones que queda después de la resta
7. Si es negativo quiere decir que alguien más se adelantó, de manera que hago un rollback de la transacción y mando un aviso al cliente.

Desde luego que sería un caso hipersimplificado puesto que las reservaciones no se hacen nada más en cuanto al número de habitaciones, sino también de lapsos de días que se ocuparán, pero el punto es que durante la transacción ya no hay ninguna intervención del usuario y todo se hace en cuestión de milésimas de segundo.

// Saludos