Cita:
|
Empezado por Leonardo
La cosa es que he he probado con una aplicacion sencilla para probar esto, solo un Grid y un datanavigator, corro 2 aplicaciones de estas y empiezo a editar un registro en mi primera aplicacion, en la segunda empiezo a editar el mismo registro que la primera aplicacion, Grabo los cambios en la primera aplicacion y despues pruebo grabar en la segunda aplicacion y se graban
|
Correcto, así es justo como tiene que comportarse con IBX o FIBPlus si dejas las transacciones con los parámetros por defecto.
Creo que no tienes claro qué significa bloqueo
optimista. - Bloqueo optimista: cuando una transacción está modificando los datos de un registro no bloquea a las otras transacciones que quieren leer ese registro, las cuales pueden seguir viendo la versión de antes de que empezara la modificación. RESUMIENDO: los escritores no bloquean a los lectores.
- Bloqueo pesimista: cuando una transacción está modificando los datos de un registro, bloquea a las otras transacciones que quieren leer ese registro, las cuales obtienen una excepción. En algunos sistemas el bloqueo puede llegar al nivel de la tabla entera. RESUMIENDO: los escritores bloquean a los lectores.
Ahora bien, tu planteas el caso de dos transacciones que quieren escribir (modificar) el mismo registro al mismo tiempo. ....Aaaaaamigo, eso es otra cosa, digamos que es algo que va más allá de que el bloqueo sea optimista, y el comportamiento a segir, pues depende, como verás ahora.
Primero, aqui tienes el manual de kinobi sobre transacciones en firebird:
http://www.terra.es/personal2/jrodri...ones-0.2.6.pdf
Y ahora te paso lo que pone el manual de los FIBPlus 5.3 sobre los parámetros de las transacciones:
--------------------------------------------------------------------------
Using the transaction parameter buffer
The transaction parameter buffer (TPB) is an optional byte vector, passed to InterBase by StartTransaction procedure, that sets up a transaction’ attributes, its operating characteristics, such as whether the transaction has read and write access to tables, or read-only access, and whether or not other simultaneously active transactions can share table access with the transaction.
The following table lists some available TPB constants:
isc_tpb_version3 InterBase version 3 transaction.
isc_tpb_consistency Table-locking transaction model. This model is serializable.
isc_tpb_concurrency High throughput, high concurrency transaction with repeatable read consistency. This mode takes full advantage of the InterBase multigenerational transaction model [Default].
isc_tpb_shared Concurrent, shared access of a specified table among all transactions; use in conjunction with isc_tpb_lock_read and isc_tpb_lock_write to establish the lock option [Default].
isc_tpb_protected Concurrent, restricted access of a specified table; use in conjunction with isc_tpb_lock_read and isc_tpb_lock_write to establish the lock option.
isc_tpb_wait Specifies that the transaction is to wait until the conflicting resource is released before retrying an operation [Default].
isc_tpb_nowait Specifies that the transaction is not to wait for the resource to be released, but instead, an update conflict error should be returned immediately.
isc_tpb_read Read-only access mode that allows a transaction only to select data from tables.
isc_tpb_write Read-write access mode of that allows a transaction to select, insert, update, and delete table data [Default].isc_tpb_lock_read Read-only access of a specified table. Use in conjunction with isc_tpb_shared, isc_tpb_protected, and isc_tpb_exclusive to establish the lock option.
isc_tpb_lock_write Read-write access of a specified table. Use in conjunction with isc_tpb_shared,
isc_tpb_protected, and isc_tpb_exclusive to establish the lock option [Default].
isc_tpb_read_committed High throughput, high concurrency transaction that can read changes committed by other concurrent transactions. Transactions in this mode do not provide repeatable read.
isc_tpb_rec_version Enables an isc_tpb_read_committed transaction to read the most recently committed version of a record even if other, uncommitted versions are pending.
isc_tpb_no_rec_version Enables an isc_tpb_read_committed transaction to read only the latest committed version of a record. If an uncommitted version of a record is pending and isc_tpb_wait is also specified, then the transaction waits for the pending record to be committed or rolled back before proceeding. Otherwise, a lock conflict error is reported at once.
You can access the transaction parameter buffer by TPB property.
--------------------------------------------------------------------------
Ahora, un ejemplo (probado):
- Abro dos ventanas de terminal y me conecto a una BD con isql.
- En las dos ventanas tecleo lo siguiente: set transaction read write no wait isolation level read committed no record_version;
- En la primera ventana tecleo: update clientes set id=2 where id=2; resultado: nada, así que no hay problema.
- Ahora, en la segunda ventana tecleo lo mismo: update clientes set id=2 where id=2; resultado:
Statement failed, SQLCODE = -901
lock conflict on no wait transaction
-deadlock
¿Es esto lo que buscas?... ya sabes, cámbia los parámetros de las transacciones. ¿Como? Tenías un programita con grid y navigator ¿no?. Entonces para IBX:
- Haz doble click sobre el componente TIBTransaction que tendrás por ahí.
- Aparece una ventana "Transaction editor", en el lado de la izquierda pica sobre "Read Committed".
- En el lado de la derecha aparece "read_commited", "rec_version" y "nowait". Sustituye a mano "rec_version" por "no_rec_version", dale a OK.
- Prueba ahora. Ejecuta dos veces tu programita.
PD: El libro de Marteens descargable de internet (la cara oculta de delphi 4) estuvo muy bien en su época (yo lo compré en su día y aún lo tengo)pero ahora, al igual que el BDE, se ha quedado atrás.