Ticketing Javascript/Typescript-Bibliothek ​

Repository ​

Beispiel ​

Einfaches Beispiel ​

Einen Broker beim App-Start erstellen und teilen. wait=0 ist ein sofortiger Versuch ohne Queue, maximal 255 s; lease liegt bei 1–250 s. Das letzte Minimum-Work-Budget ist Pflicht und darf null sein. Teilsekunden werden aufgerundet; Werte außerhalb des Bereichs oder Budget über der normalisierten Lease werden vor dem Senden abgelehnt und nie geclampt.

import { TicketBroker } from 'saro-ticketing'

const broker = TicketBroker.connect('127.0.0.1:5225')
await broker.waitReady(5)

const ticket = await broker.acquire('key', 5, 30, 2)
const token = ticket.token
// In the same DB transaction: verify/update token high-water and perform the business write.
await ticket.release()

Automatisches Close/Drop ist ein begrenzter Best-effort-Release. Wenn das Ergebnis zählt, die explizite Release-API nutzen. Der Token muss den geschützten DB-Write in derselben Transaktion fencen.

Wissenswertes zum Verhalten ​

• Sobald ein Request-Byte gesendet worden sein könnte, führt eine verlorene definitive Antwort zu Indeterminate. Kein automatisches A mit demselben Owner; der Caller betritt die Critical Section nicht.
• Cancel vor Send ist unsent; nach possible-send wird die Session geschlossen. Wurde gleichzeitig ein Grant-Token geparst, folgt ein begrenzter kompensierender exact-token Release.
• M, jedes E und malformed/oversized/unknown Responses sind session-fatal. Ungeklärte possible-send Acquires werden Indeterminate.
• B ist definitive Capacity-Ablehnung und kommt sofort. Kein interner Retry; der Caller kann mit App-Backoff und neuem Owner einen neuen Acquire starten.
• Explizite/kompensierende Releases versuchen exact token nur bis absolut 5 Sekunden ab call/enqueue. R ist Erfolg, N bereits weg/nicht aktuell; keine finale Antwort ist Fehler, nie angenommener Erfolg.
• Ticket gibt es nur bei positiver konservativer Restzeit und ausreichendem Work-Budget. Arbeit über 250 s ist vor Send unsupported.
• Token-DB-Fencing ist Pflicht: in derselben Transaktion token <= stored_high_water ablehnen, High-water und Business Write aktualisieren, dann commit/rollback und release.

Sicherheitsoptionen (Token · TLS) ​

Alle Optionen sind optional. token sollte mit den client_tokens des Servers übereinstimmen, und TLS hat vier Modi: aus / System-Vertrauensspeicher / eine angegebene CA / Verifikation überspringen (nur für Tests).

const broker = new TicketBroker({
    addrs: ['10.0.0.1:5225', '10.0.0.2:5225', '10.0.0.3:5225'],
    token: '123',
    tls: 'system-roots', // 'off' | 'system-roots' | 'insecure-skip-verify' | { ca: 'ca.crt' }
})

Die serverseitige Token-, TLS- und Cluster-Konfiguration kannst du auf der Seite Ticketing-Serverbereitstellung erzeugen.