Transacciones Concurrentes

[[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

[[egostar]]

Claro, por eso he dicho que no creo necesario hacer lo que gluglu comenta, definir dos transacciones, la reserva se genera y listo, lo demas es proceso normal y como el cliente lo pida.

Salud OS.

[luisgutierrezb]

Pues al restar habitaciones puede ser que alguien haya reservado la 2 y otro la 3 casi al mismo tiempo y por la resta el programa crea que le ganaron la habitacion, quiero imaginarme que se usa una BD "decente" la cual te debe soportar triggers y ahi en un before insert o before update segun como se manejen las tablas, que revise la habitacion, ya que ahi se haria la cola de actualizaciones a la BD...