Resource Factory for Short-Lived Session Objects
See original GitHub issueHi @rmk135
You did a great job with this library! Thank you very much for that!
Yet, I’m having a hard time with a very common approach when using Resource
: A database session should be created for each
instance of get_user
.
def create_db_session(db: Database):
session = db.create_session()
yield session
db.close_session(session)
class APIContainer:
database_session = providers.Resource(create_db_session)
class UseCaseContainer:
api = providers.DependenciesContainer()
get_user = providers.Factory(
use_cases.GetUser,
database_session=api.database_session # `database_session` must be created for every instance of `get_user`
)
But when running the application, it only creates ONE database session for the whole lifetime of the application, not N
(the number of API calls).
How is it possible to create a database session for each get_user
instance?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:10 (4 by maintainers)
Top Results From Across the Web
Resource Factory for Short-Lived Session Objects
Resource Factory for Short-Lived Session Objects.
Read more >Session (Hibernate JavaDocs)
A persistence context holds hard references to all its entities and prevents them from being garbage collected. Therefore, a Session is a short-lived...
Read more >Using the JMS API in a Java EE Application
The JMS API resources are a JMS API connection and a JMS API session. In general, it is important to release JMS resources...
Read more >Working with a session | Mastering Hibernate
As you may know, sessions are created by calling the session factory, and there is only one factory per storage unit, although you...
Read more >Developing a JMS client
If the application needs to create many short-lived JMS objects at the Session level or lower, it is important to close all the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Running into the same situation. Would love to have a database session that is essentially tied to a request/response cycle and all the dependancies that use it during that request/response cycle and closes up afterwards. It first sight the “Closing” marker does what we want but that only seems to work in combination with “Provide” when directly referencing the “Resource” not on dependancies that have the resource as a sub dependancy.
You would also need an idempotent shutdown for that on the Resource whenever you Provide multiple dependancies wrapped in a Closing that all reference that single Resource.
Ok, I see what you’re looking for. I don’t think there is anything out-of-the box to make it work that way. This is an interesting problem. I would like to address it in the framework one day.