| |||
Grabar varias tablas de manera concurrente por varios usuarios Buenas noches, tengo una duda para la creación de un sistema que puede llegar a grabar en la misma tabla por varios usuarios y quisiera me aclararan, como pgsql maneja estas operaciones; desde un cliente el usuario 1 enviara a la base de datos una información y por medio de un procedimiento almacenado se afectaran 5 tablas, pero sucede que al mismo tiempo, desde otro cliente el usuario 2, graba, y se van afectar las mismas 5 tablas y así sucesivamente..... como pgsql maneja estos procesos?? |
| ||||
Respuesta: Grabar varias tablas de manera concurrente por varios usuarios En principio, cada proceso de inserciones desde cada cliente debe ser transaccional. Esa es la clave de todo el asunto. http://www.postgresql.org.ar/trac/wi...nsactions.html http://pgsqltutorial.readthedocs.org...nsactions.html En cuanto a cómo funcionan las transacciones internamente, hay mucha documentacion para leer del tema. Lee algo de los links y dinos qué es lo que te presenta dudas.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
| |||
Respuesta: Grabar varias tablas de manera concurrente por varios usuarios buenas noches amigo muchas gracias, hasta ahí entiendo. pero realmente hablo de un sistema de ventas por ejemplo 2 personas están comprometiendo un mismo producto ejemplo producto a=10, que hay 10 productos "a" y la persona 1 compromete una existencia de 7 productos, quedan 3 mientras la otra persona tenia en pleno proceso una venta y vende 4 productos "a"..... en la configuración de sistema iría que no comprometa productos sin existencia pero esto ya ah cargado porque antes había. todo depende de quien le de primero el botón aceptar y no puede esta sujeto a esa condición en la vida real... muchas gracias de ante mano |
| |||
Respuesta: Grabar varias tablas de manera concurrente por varios usuarios entonces, guiándome de esos enlaces lo mejor es hacer un punto muerto(SAVEPOINT) antes de procesar "comprometer" y antes de procesar la "venta". bueno muchas a ambos que estén bien |
| ||||
Respuesta: Grabar varias tablas de manera concurrente por varios usuarios Mirá, el tema es complejo y lleva bastante tiempo de desarrollo, y mucho más tiempo de pruebas para poder implementarlo. La transaccionalidad es una parte de la solución, pero tienes que tener en cuenta que todo proceso concurrente donde se estén realizando ventas o entregas de biens de cualquier tipo necesitan segurizar el estado de los bienes en cada momento. ¿Que quiere decir eso? Que cada proceso de venta que se inicia debe con solo consultar, realizar la reserva de los bienes a entregar. Y cada vez que se pasa a una nueva etapa del proceso se debe validar que los bienes sigan estando disponibles, antes de cerrar la venta. Para poder hacerlo correctamente debes definir cuidadosamente los pasos de cada proceso, y ver qué validaciones y recaudo se deben tener no sólo para que la venta sea exitosa, sino para que se pueda deshacer completamente en caso de fallo o cancelación. Y esto último debe ser en cada una de las etapas de cancelación posible, incluyendo cuando se ha terminado y facturado la venta (el cliente puede pretender cancelarla, y tiene derecho a hacerlo). No existe un método único para lograr eso, hay tantos métodos como sistemas de venta se diseñan. Cada uno puede tener soluciones diferentes en el contexto de cada empresa, completamente contrapuestos a otra.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
Etiquetas: |