You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a context is created, if component A depends on B, then B will be created before A. Is there a way to insure that when a context is destroyed that the dependent is destroyed before the dependency - i.e. A is destroyed before B?
The behavior I'm seeing is the components are destroyed in the same order that they are created, which means that dependencies are destroyed before the components that use them. Hence dependencies get ripped out from under the code that needs them.
My scenario is a component which writes status updates and a database component. The status updater depends on the database, so the database gets created (and connected) before the status updater gets created, so the database is ready before any status updates get written. But on destroy, the database gets destroyed (and the connection closed) before the status updater (since that's the order they were created), so the last status updates error out because the database has been torn down before the status updater has finished.
The text was updated successfully, but these errors were encountered:
When a context is created, if component A depends on B, then B will be created before A. Is there a way to insure that when a context is destroyed that the dependent is destroyed before the dependency - i.e. A is destroyed before B?
The behavior I'm seeing is the components are destroyed in the same order that they are created, which means that dependencies are destroyed before the components that use them. Hence dependencies get ripped out from under the code that needs them.
My scenario is a component which writes status updates and a database component. The status updater depends on the database, so the database gets created (and connected) before the status updater gets created, so the database is ready before any status updates get written. But on destroy, the database gets destroyed (and the connection closed) before the status updater (since that's the order they were created), so the last status updates error out because the database has been torn down before the status updater has finished.
The text was updated successfully, but these errors were encountered: