blev8824-ai commented on issue #1702: URL: https://github.com/apache/casbin/issues/1702#issuecomment-5600981592
There is no built-in cross-store transaction, and trying to hold one open across a business DB and a policy store is the wrong pattern. Two workable approaches: 1. Transactional outbox: in the business DB transaction, write both the data change and a policy-intent record (role change, policy delta) into an outbox table, commit, then a worker applies the outbox to Casbin and marks it flushed. The business data and the decision about the intended policy change are atomic; the Casbin apply is idempotent and retryable. 2. If the policy update must be visible immediately with the business change, keep a version/epoch on the policy store and treat a mismatch as a required re-sync, so a partially-applied mutation is detected rather than trusted. The gorm-adapter specifics are secondary; the durable guarantee you actually need is that the policy delta is recorded atomically with the data change, and that applying it to Casbin is idempotent. That gives you convergence on retry instead of relying on a two-phase write that can fail halfway. One more consideration: this is a case where the policy store's decision and the business store's truth can diverge, which is why the authorization decision should be re-evaluated against the current policy at request time rather than cached. AgentKey treats the authorization decision as a runtime event with evidence, so a stale policy window is visible instead of silent: https://agentkey.us -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
