black_adept hat geschrieben:ralf.wenzel hat geschrieben:Der Vollständigkeit halber noch ein Wort an den Fragenden:
Du sperrst letztlich IMMER Tabelleneinträge [...] aber auf der DB landen dann doch wieder Tabelleneinträge.
Vom Ansatz her stimmt das schon. SAP hat das eigene Sperr-System
überhaupt nur entwickelt weil das Sperr-System der Datenbank für
ein Dialog-System mit asynchroner Verbuchung ungeeignet ist.
Die Datenbank würde Tabelleneinträge sperren - so wie das in fast
allen ERP-Systemen gemacht wird. Das ersetzt SAP mit der eigenen
Sperrlogik. Es sind logische Sperren die im Coding vorhanden sein
müssen - der Entwickler muss sich also selbst darum kümmern.
Wenn das vergessen wird sind die Folgen verheerend!
Dafür überleben die SAP-Sperren jeden Datenbank-Commit. Ohne
diese Lösung wäre ein großes System nicht operabel, praktisch jede
Transaktion würde in einem Dead-Lock enden.
black_adept hat geschrieben:[
Aber allgemein sperrt man natürlich keine Tabelleneinträge. Ein Sperrobjekt besteht aus einem Sperrschlüssel - und das sind Felder einer Dictionarystruktur. Dies kann durchaus eine Tabelle sein ( und viele Leute glauben tatsächlich, dass das nur Tabellen sein dürfen weil SAP im Enqueue-Dialog dort das Wort "Primärtabelle" verwendet ), aber dies kann genau so gut eine Struktur oder ein View sein.
Der Sperrschlüssel soll ein bestimmtes Objekt sperren. Dazu ist es
nicht notwendig alle betroffenen Tabelleneinträge zu sperren, es
genügt wenn der relevante Eintrag gesperrt wird. Es müssen sich
aber alle Programme daran halten - deshalb auch das Konzept der
Sperrbausteine (das es im R/2 noch nicht gab).
Naheliegenderweise verwendet SAP dazu einen Tabelleneintrag.
Tatsächlich kann man auch "Hugo" sperren - es ist dem Sperrserver
völlig egal welcher String da ankommt - der wird nicht verprobt.
Es müssen sich halt alle an den selben Aufbau halten wenn es
funktionieren soll.