PrimaryBasedLogViewAdaptor<TLogView,TLogEntry,TSubmissionEntry> Classe
Important
Certaines informations portent sur la préversion du produit qui est susceptible d’être en grande partie modifiée avant sa publication. Microsoft exclut toute garantie, expresse ou implicite, concernant les informations fournies ici.
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture).
Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr).
Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés.
public abstract class PrimaryBasedLogViewAdaptor<TLogView,TLogEntry,TSubmissionEntry> : Orleans.LogConsistency.ILogViewAdaptor<TLogView,TLogEntry>, Orleans.LogConsistency.ILogViewRead<TLogView,TLogEntry>, Orleans.LogConsistency.ILogViewUpdate<TLogEntry> where TLogView : class, new() where TLogEntry : class where TSubmissionEntry : SubmissionEntry<TLogEntry>
public abstract class PrimaryBasedLogViewAdaptor<TLogView,TLogEntry,TSubmissionEntry> : Orleans.EventSourcing.ILogViewAdaptor<TLogView,TLogEntry>, Orleans.EventSourcing.ILogViewRead<TLogView,TLogEntry>, Orleans.EventSourcing.ILogViewUpdate<TLogEntry> where TLogView : class, new() where TLogEntry : class where TSubmissionEntry : SubmissionEntry<TLogEntry>
type PrimaryBasedLogViewAdaptor<'LogView, 'LogEntry, 'SubmissionEntry (requires 'LogView : null and 'LogView : (new : unit -> 'LogView) and 'LogEntry : null and 'SubmissionEntry :> SubmissionEntry<'LogEntry>)> = class
interface ILogViewAdaptor<'LogView, 'LogEntry (requires 'LogView : null and 'LogView : (new : unit -> 'LogView) and 'LogEntry : null)>
interface ILogViewRead<'LogView, 'LogEntry (requires 'LogView : null and 'LogView : (new : unit -> 'LogView) and 'LogEntry : null)>
interface ILogViewUpdate<'LogEntry (requires 'LogEntry : null)>
interface ILogConsistencyDiagnostics
Public MustInherit Class PrimaryBasedLogViewAdaptor(Of TLogView, TLogEntry, TSubmissionEntry)
Implements ILogViewAdaptor(Of TLogView, TLogEntry), ILogViewRead(Of TLogView, TLogEntry), ILogViewUpdate(Of TLogEntry)
- TLogView
Vue définie par l’utilisateur du journal
- TLogEntry
Type des entrées de journal
- TSubmissionEntry
Type d’entrées de soumission stockées dans la file d’attente en attente
- Héritage
-
PrimaryBasedLogViewAdaptor<TLogView,TLogEntry,TSubmissionEntry>
- Implémente
Primary |
Construisez un instance pour les paramètres donnés. |
Primary |
Construisez un instance pour les paramètres donnés. |
Last |
Stockez le dernier problème qui s’est produit lors de la lecture ou de la mise à jour du principal. A la valeur Null en cas de réussite. |
stats |
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture). Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr). Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés. |
Configuration |
Configuration à plusieurs clusters actuelle pour ce instance de grain. |
Confirmed |
Longueur du préfixe confirmé du journal |
Confirmed |
Affichage confirmé du journal (ne reflétant que les entrées confirmées) |
Host |
Grain qui utilise cet adaptateur. |
Services |
Services d’exécution requis pour l’implémentation des notifications entre les instances de grain dans un cluster différent. |
Support |
Si ce cluster prend en charge l’envoi de mises à jour |
Tentative |
Vue locale et provisoire du journal (reflétant les entrées confirmées et non confirmées) |
Unconfirmed |
Liste des entrées envoyées qui n’apparaissent pas encore dans le préfixe confirmé. |
Unresolved |
retourne une liste de tous les problèmes d’intégrité de connexion qui n’ont pas encore été restaurés. De tels problèmes sont observés lors de la communication avec le serveur principal ou lors de la tentative de notification d’autres clusters, par exemple. |
Broadcast |
Envoyer un message de notification à toutes les instances distantes |
Confirm |
Confirmez toutes les entrées envoyées. Attend que toutes les entrées précédemment envoyées apparaissent dans le préfixe confirmé du journal. |
Copy |
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture). Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr). Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés. |
Disable |
Désactiver la collecte de statistiques |
Enable |
la méthode étant virtuelle, les sous-classes peuvent ajouter leurs propres événements |
Ensure |
Bloquer jusqu’à ce que ce cluster soit joint au multicluster. |
Get |
Attendez que ce cluster ait reçu une configuration au moins aussi nouvelle que timestamp |
Get |
Lire la version de l’état global mis en cache. |
Get |
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture). Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr). Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés. |
Get |
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture). Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr). Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés. |
Get |
Obtenir les états |
Initialize |
Définir la valeur initiale de l’affichage confirmé (une vue du journal vide) |
Is |
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture). Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr). Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés. |
Last |
Lire l’état global mis en cache. |
Make |
Créez une entrée de soumission pour l’entrée de journal envoyée. Utilisation d’un paramètre de type pour pouvoir ajouter des informations spécifiques au protocole à cette classe. |
Merge(INotification |
Fusionner deux messages de notification, pour le traitement par lot. Remplacez pour gérer les sous-types de notification. |
Notify |
envoyer des notifications d’échec |
On |
Appelé lorsque la configuration du multicluster change. |
On |
Gérer les messages de protocole. |
On |
Gérer les messages de protocole. |
On |
Appelé par MultiClusterOracle en cas de modification de configuration. |
On |
Gérer les messages de notification. Remplacez cette valeur pour gérer les sous-types de notification. |
On |
Appelé à partir du réseau |
On |
Appelé à partir du réseau |
Post |
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture). Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr). Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés. |
Post |
Appelé pendant la désactivation, juste après le défini par OnDeactivateAsync()l’utilisateur. |
Pre |
Appelé lors de l’activation, juste avant le défini par OnActivateAsync()l’utilisateur. |
Process |
Traiter les notifications stockées pendant le cycle de travail. Remplacez pour gérer les sous-types de notification. |
Read |
Lisez l’état principal le plus récent. Doit bloquer/réessayer jusqu’à ce que la réussite soit réussie. Ne doit pas lever d’exceptions, mais les enregistrer dans LastPrimaryIssue |
Remove |
parcourir les mises à jour et supprimer toutes les mises à jour conditionnelles qui ont déjà échoué |
Retrieve |
Modèle général pour construire des adaptateurs de vue de journal basés sur une base de données primaire en lecture et écriture séquentielle. Nous l’utilisons pour construire différents fournisseurs de cohérence des journaux, tous suivant le même modèle de base (lecture et écriture de la dernière vue depuis/vers le serveur principal, et envoi de notifications après l’écriture). Notez que le journal lui-même est temporaire, c’est-à-dire qu’il n’est pas réellement enregistré dans le stockage : seule la vue la plus récente et certaines métadonnées (la position du journal et les indicateurs d’écriture) sont stockées dans le serveur principal. Il est sûr d’entrelacer les appels à cet adaptateur (à l’aide du planificateur de grain uniquement, bien sûr). Les sous-classes remplacent ReadAsync et WriteAsync pour lire/écrire à la classe primaire. Les appels au serveur principal sont sérialisés, c’est-à-dire jamais entrelacés. |
Submit(TLog |
Envoyez une seule entrée de journal à ajouter au journal global, à la position actuelle ou ultérieure. |
Submit |
Envoyez une plage d’entrées de journal à ajouter atomiquement au journal global, à la position actuelle ou ultérieure. |
Synchronize() |
Obtenez la dernière vue du journal et confirmez toutes les entrées envoyées. Attend que toutes les entrées précédemment envoyées apparaissent dans le préfixe confirmé du journal et force l’actualisation du préfixe confirmé. |
Try |
Essayez d’ajouter une seule entrée de journal à la position actuelle du journal. |
Try |
Essayez d’ajouter une plage d’entrées de journal de manière atomique à la position actuelle du journal. |
Write |
Appliquez les entrées en attente au serveur principal. Doit bloquer/réessayer jusqu’à ce que la réussite soit réussie. Ne doit pas lever d’exceptions, mais les enregistrer dans LastPrimaryIssue |