Diseño de la personalización escalable: transacciones de bases de datos

Nota

Este es el segundo de una serie de temas sobre el diseño de la personalización escalable. Para comenzar, consulte Diseño de la personalización escalable en Microsoft Dataverse.

Uno de los conceptos fundamentales que encierran muchos de los retos que surgen aquí es el de las transacciones de bases de datos. En Dataverse, la base de datos está en el centro de casi todas las solicitudes al sistema y es el sitio donde la coherencia de los datos se aplica principalmente.

• Ninguna de las operaciones de Dataverse para aplicaciones, bien interna o como parte de las personalizaciones de código, funciona totalmente de forma aislada.
• Todas las operaciones de datos de Dataverse interactúan con los mismos recursos de base de datos, bien en el nivel de los datos o de la infraestructura como el procesador, la memoria o el uso de E/S.
• Para protegerse frente a los cambios conflictivos, cada solicitud bloquea recursos para poder verse o modificarse.
• Esos bloqueos se efectúan dentro de las transacciones y no se liberan hasta que la transacción se confirma o anula.

Familiarizarse con las transacciones y los bloqueos

Una razón habitual por la que los problemas surgen en esta área está la falta de conocimiento sobre cómo las personalizaciones pueden afectar a las transacciones.

Aunque los detalles de cómo se hace esto están fuera del alcance de este artículo, el elemento más sencillo que se debe considerar es cómo Dataverse interactúa con los datos en su base de datos. SQL Server determina los bloqueos adecuados que se realizarán las transacciones en esos datos como por ejemplo:

• Cuando se crea un registro, se genera un bloqueo de escritura en ese registro.
• Cuando se actualiza un registro, se aplica un bloqueo de escritura en el registro.
• Cuando un bloqueo se aplica en una tabla o un registro, también se aplicará en los registros de índice correspondientes.

Sin embargo, es posible influir en el alcance y la duración de estos bloqueos. También es posible indicar a SQL Server que no se requiere un bloqueo para determinados escenarios.

Consideremos el bloqueo de la base de datos de SQL Server y la repercusión de las solicitudes independientes que intentan tener acceso a los mismos datos. En el siguiente ejemplo, al crear una cuenta se han configurado una serie de procesos, algunos con complementos que se desencadenan en cuanto se crea el registro y algunos en un flujo de trabajo asincrónico relacionado que se inicia en la creación.

El ejemplo muestra las consecuencias cuando un proceso de actualización de cuenta tiene un procesamiento posterior complejo mientras que otra actividad también interactúa con el mismo registro de cuenta. Si se procesa un flujo de trabajo asincrónico mientras que la transacción de la cuenta está aún en curso, este flujo de trabajo podría bloquearse a la espera de obtener un bloqueo de actualización para cambiar el mismo registro de cuenta, que aún está bloqueado.

Debe tenerse en cuenta que las transacciones solo se retienen mientras dure una solicitud específica para la plataforma. Los bloqueos no se retienen en una sesión de usuario o mientras se muestra la información en la interfaz de usuario. En cuanto la plataforma ha completado la solicitud, libera la conexión de la base de datos, la transacción relacionada y cualquier bloqueo que haya aplicado.

Bloqueo

Mientras que el tipo de bloqueo del ejemplo anterior puede ser un inconveniente por sí mismo, este bloqueo también puede traer consecuencias más serias so considera que Dataverse es una plataforma que puede procesar cientos de acciones simultáneas. Mientras que retener un bloqueo en un registro de cuenta individual puede tener implicaciones razonablemente limitadas, ¿qué sucede cuando se disputa un recurso con más intensidad?

Por ejemplo, cuando se proporciona un número de referencia único a cada cuenta puede causar que un solo recurso que esté registrando los números de referencia usados se bloquee por cada proceso de creación de cuenta. Como se describe en el ejemplo de numeración automática, si muchas cuentas que se generan en paralelo, con superposición de solicitudes que necesitan tener acceso a ese recurso de numeración automática, este se bloquea hasta que completen la acción. Cuanto más dure cada proceso de creación de cuenta y se produzcan más solicitudes simultáneas, más bloqueos habrá.

Mientras que la primera solicitud que logre el bloqueo de recurso de numeración automática se completará fácilmente, la segunda solicitud necesita esperar a que finalice la primera para poder comprobar cuál es el siguiente número de referencia único. La tercera solicitud tiene que esperar a que las dos anteriores solicitudes se completen. Cuantas más solicitudes haya, más prolongado es el bloqueo. Si hay suficientes solicitudes, y cada una dura bastante, ese retraso puede impulsar las solicitudes posteriores hasta tal punto que se agote el tiempo de espera, aunque individualmente se puedan completar correctamente.

Liberación del bloqueo

Hay dos razones principales por las que un bloqueo no se libera, sino que se retiene hasta que se complete la transacción:

• El servidor de base de datos retiene el bloqueo por razones de uniformidad en caso de que la transacción haga más adelante otra solicitud para actualizar el elemento de datos.
• El servidor de base de datos también debe tener en cuenta el hecho de que un error o comando de anular puede provocar la reversión de la totalidad de la transacción, por lo que necesita retener los bloqueos mientras dure la transacción para garantizar la coherencia.

Es importante reconocer que aunque el proceso puede haber completado las interacciones con una determinada porción de datos, el bloqueo es retenido hasta completar y confirmar la transacción completa. Cuanto más se prolongue la transacción, más tiempo se retiene el bloqueo, evitando completar otros subprocesos que interactúan con esos datos. Como se muestra más adelante, esto también incluye personalizaciones relacionadas que operan dentro de la misma transacción y pueden prolongar de forma notable la duración de transacciones como los flujos de trabajo síncronos.

En el siguiente ejemplo, el bloqueo de escritura en una entidad personalizada en el complemento previo a la creación para una cuenta está bloqueado hasta que toda la lógica ligada a la creación de la cuenta se complete.

Errores intermitentes: temporización

El comportamiento intermitente es un síntoma obvio de bloqueo en la actividad simultánea. Si la repetición exacta de la misma acción más adelante se realiza correctamente mientras que antes había fallado, probablemente el error o la lentitud fueron producidos por algo que sucedió de forma simultánea.

Es importante tener esto en cuenta ya que la depuración un problema normalmente implica dejar la funcionalidad en su nivel más básico. Sin embargo, cuando el problema ocurre solo intermitentemente, es posible que necesite buscar dónde causa el conflicto la acción que falla con otra del sistema y necesita buscar los posibles puntos conflictivos. Puede mitigar el conflicto optimizando un proceso individual; sin embargo, cuanto más rápido sea el procesamiento, menos posibilidades hay de que la actividad entre en conflicto con otros procesos.

Control de las transacciones

Mientras que en la mayoría de los casos la forma en que se usan las transacciones puede dejarse a la plataforma que lo administre, hay situaciones donde la lógica necesaria es lo suficientemente compleja que resulta necesario entender y gestionar las transacciones para lograr los resultados deseados. Dataverse ofrece muchos enfoques de personalización diferentes que tienen un impacto distinto en la forma en que se usan las transacciones.

Cuando entienda cómo cada tipo de personalización participa en las transacciones de la plataforma, podrá modelar situaciones complejas de forma eficaz en Dataverse y predecir su comportamiento.

Como se mencionó anteriormente, una transacción solo se retiene durante la duración de una solicitud a la plataforma, no es algo se mantenga después de completar el paso de la plataforma. Esta duración limitada evita que un cliente externo retenga las transacciones durante largos periodos de tiempo y se bloquen otras actividades de la plataforma.

El trabajo de la plataforma es mantener la coherencia en la canalización de las transacciones en la plataforma y cuando sea apropiado permitir a las personalizaciones participar en la misma transacción.

Cómo utilizan las transacciones las aplicaciones basadas en modelos

Antes de poder saber cómo las personalizaciones interactúan con la plataforma, resulta útil saber cómo las solicitudes basadas en modelos utilizan las solicitudes a la plataforma, y cómo afecta al uso de las transacciones.

Operation	Description
Formularios (Retrieve)	• Poca repercusión en otros usos.
Create	• Efectúa una solicitud de creación en la plataforma. • Poca repercusión en otras actividades, ya que un nuevo registro no debe tener nada que lo bloquee. • Potencialmente puede bloquear consultas con bloqueo para la totalidad de la tabla hasta que se complete. • A menudo puede desencadenar acciones relacionadas en la personalización, lo que puede tener repercusiones.
Update	• Efectúa una solicitud de actualización en la plataforma. • Resulta más probable que tenga conflictos. Un bloqueo de actualización bloquea cualquier otra cosas que actualice o lea ese registro. • A menudo desencadena otras actividades. • En algunos casos raros, un bloqueo de actualización puede bloquear un bloqueo de lectura. Un ejemplo de dónde puede ocurrir esto es cuando los metadatos de Dataverse se están cambiando: las lecturas realizadas por una transacción de cambio de metadatos de Dataverse se bloquearán mediante bloqueos de actualización.
Ver (RetrieveMultiple)	• Poca repercusión en otros usos. • Las consultas de bajo rendimiento pueden abrumar los recursos de la base de datos y alcanzar los tiempos de espera.

Canalización de eventos: paso de la plataforma

Cuando se inicia una canalización de eventos, una transacción de SQL se crea para incluir el paso de la plataforma. Esto garantiza que toda la actividad de bases de datos realizada por la plataforma ser realiza de forma uniforme. La transacción se crea al inicio de la canalización de eventos y se confirma o anula cuando se complete el procesamiento, dependiendo de si se realiza correctamente.

Solicitudes de personalización

También es posible participar en la transacción iniciada de la plataforma dentro de las personalizaciones. Cada tipo de personalización participa en transacciones de forma diferente. En las siguientes secciones se describen.

• Complementos de sincronización (antes o después de la operación: en el contexto de la transacción)
• Complementos de sincronización (antes y después de la operación: en el contexto de la transacción)
• Complementos de sincronización (PreValidation: en un contexto externo a la transacción)
• Complementos de sincronización (PreValidation: en el contexto de la transacción)
• Complementos asincrónicos
• Resumen de uso de transacciones del complemento
• Flujos de trabajo sincrónicos
• Flujos de trabajo asincrónicos
• Actividad de flujo de trabajo personalizado
• Acciones personalizadas
• Solicitudes de servicio web

Complementos de sincronización (antes o después de la operación: en el contexto de la transacción)

Cuando los complementos se registran para un evento, se pueden registrados en una etapa PreOperation o PostOperation que esté dentro de la transacción. Cualquier solicitud de mensajes desde el complemento se realiza dentro de la transacción. Esto significa que la duración de la transacción y los bloqueos aplicados, se ampliarán.

Complementos de sincronización (antes y después de la operación: en el contexto de la transacción)

Los complementos pueden registrarse en las etapas PreOperation y PostOperation. En este caso la transacción se puede ampliar incluso más porque se prolonga desde el principio del complemento PreOperation hasta que el complemento PostOperation se complete.

Complementos de sincronización (PreValidation: en un contexto externo a la transacción)

Un complemento también se puede registrar para que se aplique fuera de las transacciones de la plataforma si se registrado en la etapa PreValidation.

Nota

NO crea su propia transacción. Como resultado, se actúa de forma independiente en cada solicitud de mensaje en el complemento dentro de la base de datos.

Este escenario se aplica solo cuando se invoca PreValidation como la primera etapa de un evento de la canalización. Aunque el complemento se registra en la etapa PreValidation, es posible que participará en una transacción como la siguiente sección describe. No se puede asumir que un complemento PreValidation no participa en una transacción, aunque es posible comprobar en el contexto de la ejecución si éste es el caso.

Complementos de sincronización (PreValidation: en el contexto de la transacción)

El escenario relacionado se produce cuando se registra un complemento PreValidation pero el evento relacionado de la canalización se activa por la solicitud de mensaje desde una transacción existente.

Tal como muestra el siguiente diagrama, crear una cuenta puede hacer que un complemento PreValidation se desarrolle inicialmente fuera de una transacción cuando se realiza la creación inicial. Si, como parte del complemento posterior, una solicitud de mensaje se realiza para crear una cuenta secundaria relacionada porque esa segunda canalización de eventos se inicia desde dentro de la canalización principal, participa en la misma transacción.

En este caso, el complemento PreValidation detecta que ya existe una transacción y participa en esa transacción aunque se haya registrado en la etapa PreValidation.

Como se indicó anteriormente, el complemento puede comprobar el contexto de ejecución para la propiedad IsInTransaction, que indica si este complemento se desarrolla en una transacción o no.

Complementos asincrónicos

Un complemento también se puede registrar para que se desarrolle de forma asincrónica. En este caso, el complemento también actúa fuera de la transacción de plataforma.

Nota

El complemento no crea su propia transacción; se actúa de forma independiente en cada solicitud de mensaje en el complemento.

Resumen de uso de transacciones del complemento

Para resumir:

• Los complementos sincrónicos participan normalmente en las transacciones.
• Los complementos asincrónicos nunca participan en una transacción de plataforma; cada solicitud se realiza de forma independiente.
• Los complementos PreValidation no crean una transacción pero participan si ya existe una.

Evento	Nombre de la fase	La transacción aún no existe	La transacción ya existe
Anterior al evento	Prevalidación	No se crearon transacciones. No participa en la transacción; cada solicitud usa una transacción independiente para la base de datos	Participa en la transacción existente
Anterior al evento	PreOperation	Participa en la transacción existente	Participa en la transacción existente
Posterior al evento	PostOperation	Participa en la transacción existente	Participa en la transacción existente
Asincrónico	N/A	No se crearon transacciones. No participa en la transacción; cada solicitud usa una transacción independiente para la base de datos	N/D

Flujos de trabajo sincrónicos

Desde la perspectiva de las transacciones, los flujos de trabajo sincrónicos actúan complementos anteriores y posteriores. Por lo tanto, se desarrollan en la transacción de canalización de la plataforma y pueden tener el mismo efecto en la duración de toda la transacción.

Flujos de trabajo asincrónicos

Los flujos de trabajo asincrónicos se desencadenan fuera de la transacción de plataforma.

Nota

El flujo de trabajo TAMPOCO crea su propia transacción por tanto se actúa de forma independiente sobre cada solicitud de mensaje en el flujo de trabajo.

En el siguiente diagrama se muestra el flujo de trabajo asincrónico que se desarrolla fuera de la transacción de la plataforma y de cada paso que inicia su propia transacción independiente.

Actividad de flujo de trabajo personalizado

Las actividades de flujo de trabajo personalizadas se desarrollan en el contexto principal del flujo de trabajo.

• Flujo de trabajo de la sincronización: actúa dentro de la transacción
• Flujo de trabajo asincrónico: actúa fuera de la transacción

En el siguiente diagrama se muestran las actividades personalizadas que actúan primero en un flujo de trabajo sincrónico y después en un flujo de trabajo asincrónico.

Acciones personalizadas

Las acciones personalizadas pueden crear sus propias transacciones. Esta una característica fundamental. Una acción personalizada puede crear una transacción independiente fuera del paso de la plataforma dependiendo de si está configurada para establecer Habilitar reversión.

• Habilitar reversión establecido
  • Si se invoca a través de solicitud de mensaje desde un complemento que se ejecuta dentro de la transacción, y está establecido Habilitar reversión, la acción personalizada se desarrolla en la transacción existente.
  • La acción personalizada crea de lo contrario una nueva transacción y se ejecutará dentro de ella.
• Habilitar reversión no establecido
  • La acción personalizada no se desarrollará en una transacción.

Solicitudes de servicio web

Cuando las solicitudes se realizan de forma externa a través de servicios web, se crea una canalización y la gestión de la transacción se desarrolla dentro de la canalización como se indicó anteriormente, pero una transacción no se mantendrá después de devolver la respuesta. Dado que se desconoce el tiempo que puede transcurrir hasta la solicitud siguiente, la plataforma no permite bloquear recursos que bloquearían otras actividades.

Cuando se realizan múltiples solicitudes en un complemento con el mismo contexto de ejecución, el contexto de ejecución común es el que mantiene la referencia de la transacción y garantiza con complementos sincrónicos que cada solicitud se realiza dentro de la misma transacción. La capacidad de mantener un contexto de ejecución en las solicitudes no está disponible fuera de los complementos, por lo que una transacción no se puede mantener a través de solicitudes independientes realizadas de forma externa.

Hay dos mensajes especiales donde se pueden pasar múltiples acciones a la plataforma de Dataverse como parte de una sola solicitud de servicio web.

Mensaje	Descripción
ExecuteMultiple	Esto permite que múltiples acciones independientes se pasen dentro de la misma solicitud de servicio web. Cada una de estas solicitudes se realiza de forma independiente dentro de la plataforma, por tanto, no hay contextos de transacción retenidos entre las solicitudes.
ExecuteTransaction	Esto permite procesar diversas acciones dentro de la misma transacción de base de datos, de forma similar a las múltiples solicitudes de mensaje realizadas desde un complemento de forma sincrónica. Esta capacidad también tendrá implicaciones similares a la realización de múltiples solicitudes de mensaje, es decir, si cada acción se prolonga durante mucho tiempo (por ejemplo realizando consultas costosas o desencadenando una cadena extensa de complementos o flujos de trabajo sincrónicos relacionados), podría provoca problemas de bloqueo a un nivel más general de la plataforma.

Solicitudes de API web (OData) en complementos

No use las solicitudes de API web (OData) dentro de un complemento a la misma organización que el complemento. Use siempre los métodos IOrganizationService. Esto hace posible que el contexto de la transacción se pase para que la operación pueda participar en la transacción de la canalización.

Pasos siguientes

Además de las transacciones de base de datos, es importante apreciar el impacto que múltiples operaciones de datos simultáneas pueden tener en el sistema. Más información: Diseño de la personalización escalable: problemas de simultaneidad

Nota

¿Puede indicarnos sus preferencias de idioma de documentación? Realice una breve encuesta. (tenga en cuenta que esta encuesta está en inglés)

La encuesta durará unos siete minutos. No se recopilan datos personales (declaración de privacidad).