pierrejeambrun commented on issue #43897: URL: https://github.com/apache/airflow/issues/43897#issuecomment-2493873910
> If we implement this on the FastAPI side, I would add a wrapper async def set_async around the _set method to allow the use of asyncio.gather. Additionally, I have verified that the SQLAlchemy session is thread-safe for this case, as the same session object will be used across all coroutines. Ref: https://github.com/sqlalchemy/sqlalchemy/issues/5828 The `Variable.set` method is synced, so basically it will never release and block the main loop. The way you can run sync code from async route is with `run_in_executor` from asyncio or `run_in_threadpool` from `starlette`. https://sentry.io/answers/fastapi-difference-between-run-in-executor-and-run-in-threadpool/ >Additionally, I have verified that the SQLAlchemy session is thread-safe for this case, as the same session object will be used across all coroutines. Ref: https://github.com/sqlalchemy/sqlalchemy/issues/5828 I don' think so. As mentioned above you will have to use multiple threads otherwise that would just basically be the same a sequential requests (because the main loop is blocked) => might run into problem with one session shared. And there is a note about `AsyncSession` which are not threadsafe` in the issue you linked. Worth trying both, I have no preference at this point. (Maybe inside FastAPI is cleaner because from the CLI point of view, everything is handled the same -> through 1 call to the API, but not sure if this will be super easy to do because of the things highlighted above) -- 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]
