nicht angemeldet
Rolf bAh. Dass MyISAM immer nur Table-Locks macht, wusste ich gar nicht. Immer dieses Halbwissen bei den LAMP-Autodidakten...
Ja, auf die relevante User-Authentication-&-Login-Tabelle muss bei bei jedem Request des Users ein erfolgreiches Update geschehen. Das ist gerade der Kern der Klasse. Es wird requestbasiertes Rechtemnagement betrieben und nicht sessionbasiertes
Ja gut. Das ist eine Sache. Du musst pro Session irgendwo festhalten, wie alt sie ist und welcher User darin angemeldet ist. Eventuell hältst Du darin auch den serialisierten Sessionstate. Aber das ist eine Row pro User und es ist normalerweise eine eigene Tabelle, nicht die eigentliche User-Tabelle. Hier ist Locking auf Zeilenebene auf jeden Fall sinnvoll und InnoDB angesagt.
Das heißt, dass sich die Rechte eines Users von Request zu Request ändern können, sogar innerhalb eines Dokuments aufgrund von primary und dependent Requests.
Hab ich jetzt nicht ganz verstanden, das sind jetzt die Tiefen deines Konzepts. Für mich klingt das jetzt nach einem Rechte-Manager, der den aktuellen User kennt und der von den Requests (primary oder dependent) gefragt wird, ob denn das Recht R für Modul X im Projekt Y gegeben ist. Der Mananger liest dann die hinterlegten Berechtigungen für User, Projekt und Modul, legt sie in einen requestbezogenen Cache und gibt dann "true" oder "false" zurück. Oder die vorhandene Rechtestufe. Wie auch immer. Jedenfalls würde ich mir gut überlegen, ob der Rechtemanager proaktiv beim Start des Requests alle Rechte eines Users einsammeln sollte. Wenn sich ein Request nur auf ein Projekt bezieht, der User aber in 20 Projekten steckt, dann liest Du viel zu viel.
Aber das ist ein anderes Thema als die Session, oder? Die hinterlegten Berechtigungen eines Users sollten sich doch im NORMALFALL selten ändern, die werden einmal festgelegt und dann zu 99,99% nur noch gelesen. Ob es Row- oder Table-Locks gibt, ist dann fast egal. Das Update auf die Session-Tabelle muss auch nicht transaktional an das Lesen der Berechtigungen gebunden sein. Wenn das Session-Update fehlschlägt, würde ich 2-3 Retries versuchen und dann den Request abbrechen, denn das stinkt nach einem Grundsatzproblem.
Rolf
TS
MudGuard
Der Martin