java - ejemplo - spring ldap example

Transacción LDAP en Java

Question

Tengo que crear una característica de inserción masiva para nuestra herramienta de administración de usuarios. Creamos una pequeña biblioteca interna utilizando LDAP de primavera, y todo funciona bien para la administración de usuarios únicos (CRUD).

Me gustaría intentar insertar cientos de registros a la vez y deshacerlos si algo sale mal.

¿Hay alguna manera de crear transacciones en LDAP como existe en las bases de datos?

Gracias por tus ideas

Answer 1

Eche un vistazo a la documentación: http://static.springsource.org/spring-ldap/docs/1.2.0-rc1/reference/#transactions

Answer 2

Este es un seguimiento de @adrianboimvaser.

Solo una nota de que el soporte de la transacción Spring LDAP no usa transacciones XA, sino transacciones de compensación "Lógicas", por lo que la reversión de LDAP será una acción de compensación contra LDAP. Si bien esta es una mejora en comparación con las transacciones, tenga en cuenta que esto no es lo mismo que una transacción típica "como existe en las bases de datos". es decir, las propiedades ACID de las transacciones no son compatibles.

Tenga en cuenta que, aunque se utiliza la misma transacción lógica, esta no es una transacción JTA XA; no se realizará una confirmación en dos fases, por lo que la confirmación y la reversión pueden dar resultados inesperados.

Por ejemplo: si agrega 100 entradas a LDAP, cada registro se agregará uno por uno a LDAP. Si el último complemento falla, la acción de deshacer será eliminar las 99 entradas previamente creadas dentro de la transacción. Sin embargo, si por alguna razón (por ejemplo, la conectividad de red se reduce a LDAP, que es lo que provocó la falla de la entrada 100), las primeras 99 entradas no se pueden eliminar. Luego, aunque haya intentado deshacer la transacción, tendrá una incoherencia entre base de datos y LDAP. es decir, habrá 99 registros en LDAP (porque no se pudieron eliminar) que no existen en la base de datos (porque esos registros nunca se insertaron o se retrotrajeron realmente).

No estoy seguro de cuál es su situación, pero si tiene frecuentes grandes actualizaciones de LDAP, puede considerar usar una base de datos real para evitar los dolores de transacción y optimizar el rendimiento ya que LDAP está diseñado para lecturas rápidas con escrituras relativamente más lentas.