[feature] better session management for newSyncedAdapter()

[CheaterScript]

Hi！
I am a MongoDB novice and would like to ask two questions. Why doesn’t the newSyncedAdapter API return the current session or call the current session.endSession?
Because I want to perform some operations before submitting the transaction and found that I need to manage the session myself, which doesn’t seem reasonable. Also, I see that people online will call session.endSession after a transaction is completed, but this library only calls session.endSession in the close method. Other APIs do not call session.endSession after the session is committed or discarded. Is there any problem with this? Hope to get your help.

[casbin-bot]

@nodece @Zxilly @Shivansh-yadav13

[hsluoyz]

@CheaterScript hi, can you make a PR to return the current session in the function?

[kohtala]

I share the confusion on the transaction support.

I understood @CheaterScript, and I, have other database changes to put in the same transaction with casbin policy changes. For example, if the policy refers to a user, and I'd like to have the user created/deleted/modified in the same transaction such that the user and policy would both be changed or neither would be changed.

As @CheaterScript points out, keeping the session in an instance attribute is confusing. I do not find what in the design would enforce the rule that at any given time, you can have at most one open transaction for a session.

Looking at the interfaces, I'd expect I should get a copy of the enforcer for policy changes with a copy of the adapter that performs all database operations in the transaction session. The session may have been created earlier for example to create the user before the policy. Also, the session would be committed or aborted outside and independent of the adapter. Once transaction is committed, the changes would be seen in the enforcer used by other concurrent requests.

The gorm-adapter seems to implement the Transaction method almost like this with copies. It wants to own the transaction, but I do not see why. If two libraries were to want to own the transaction, you could not use them in the same transaction.

Transactions have also the complexity of when the enforcer will take the new rules into use. You'd want the enforcer to be part of the transaction.

[hsluoyz]

@kohtala hi, can you make a PR to fix it?