multiples clientes haciedno el mismo insert

[lusop]

Buenas,

Estoy preparando una aplicacion java centralizada en la que varios clientes van a recolectar informacion de unos elementos, la van a tratar y van a realizar un insert de muchos elementos en el servidor. El problema es que entre los clientes no hay comunicacion alguna, asi que muchos de sus inserts van a a producir error porque algun otro cliente ya ha insertado ese elemento.

Como se trata esta situacion si:
- no es posible que haya comunicacion entre clientes.
- Los clientes disponen de recursos practicamente ilimitados; el servidor va a ser relativamente reducido.

Cual es la mejor aproximacion en el cliente? Insert tras insert, y seguir aunque fallen? Pedir primero la sublista de los que no estan en su lista y luego realizar los insert?

Gracias!

[gnzsoloyo]

Estudiar el tema de transacciones: Concurrencia y transacciones.

[lusop]

gnz, siempre estas ahi, macho. Gracias por la informacion, pero este tema ya lo conozco.

Lo que pregutno es una aproximacion practica a este tema. Lo unico que se me ocurre ahora mismo es hacer los inserts de uno en uno (sin transaccion) e ignorar el error que sea que ya existe.

La unica ventaja que tengo es que los elementos ya tienen id cuando el cliente los encuentra.

[gnzsoloyo]

El problema es que entre los clientes no hay comunicacion alguna, asi que muchos de sus inserts van a a producir error porque algun otro cliente ya ha insertado ese elemento.

El segundo insert queda en espera durante X tiempo (configurable) hasta que la tabla queda liberada por el primero. En ese estado, si la clave ya existe, simplemente no ingresará.
En este contexto puedes usar un INSERT IGNORE para contrar el evento de error si el error no te interesa, pero lo que debes tener en cuenta es que la PK de esa tabla no puede ser en ese caso autoincremental. Debe estar creada en base a campos propios de la tabla, porque sería la única forma de evitar duplicaciones.
Si sólo puedes manejar autoincrementales o numéricos controlados por aplicación, deberás administrar el ingreso de próxima clave antes de la inserción, lo que implica una consulta. Siendo que los vas a manejar con transacciones eso no debería ser problema: bastaría conque la consulta de la próxima clave estuvie4se también dentro de la transacción.

Lo que te conviene es graficar en alguna planilla o en diagrama, los diferentes estados de concurrencia posible para ver cómo resolver el tema.

[lusop]

La PK es un campo propio. Si dos clientes encuentran el mismo elemento y hacen el insert, ambos insert llevan la misma PK.

Bueno, la opcion es buena para mysql pero no es seguro que vaya aa ser el sistema que usemos.

Lo dejare en stand-by porque hay cosas con mayor prioridad.

Mcuahs gracias GNZSOLOYO

[gnzsoloyo]

Bueno, la opcion es buena para mysql pero no es seguro que vaya aa ser el sistema que usemos.

Hay variaciones en cuanto a la implementación de las transacciones, pero el concepto básico es general para todos los DBMS. Lo que deberás estudiar, entonces, es lo que debes hacer en el DBMS que elijas finalmente.
Recuerda que esa elección afectará todo lo que hagas en SQL... y no solamente las transacciones.