| --- | --- |
| Bugzilla Link | 543789 |
| Status | NEW |
| Importance | P3 enhancement |
| Reported | Jan 24, 2019 09:49 EDT |
| Modified | Jan 24, 2019 09:49 EDT |
| Version | 2.1.0 |
| Reporter | Zoltan Ujhelyi |
Description
We have seen issues where query engines and event-driven transformations are managed by separate components; in such cases when query engines are stopped (e.g. because of model unloading) the transformation engine gets into an inconsistent state, e.g. the engine stops sending notifications, but the model update listeners are still active. An approach to handle this is to register a ViatraQueryEngineLifecycleListener to the engine, and dispose the transformation on the appropriate events.
This process could be made automatic: we could provide this support in a generic way, allowing transformation developers to use it. The question is what kind of transformations should rely on these. A first idea:
Event-driven transformations could always register for auto-dispose, unless asked not to. This would allow not to trigger any changes after some event sources are turned off.
For batch transformations, control flow is provided by the transformation developer, thus we are not reacting to model changes directly. In such cases automatic dispose is unnecessary, and might be surprising as well. On the other hand, statements could fail if the underlying engine is disposed.
In case of generic EVM transformations we could implement the feature in a generic way, but we must ask the developer to turn it on, as this is not the only event source.
| --- | --- | | Bugzilla Link | 543789 | | Status | NEW | | Importance | P3 enhancement | | Reported | Jan 24, 2019 09:49 EDT | | Modified | Jan 24, 2019 09:49 EDT | | Version | 2.1.0 | | Reporter | Zoltan Ujhelyi |
Description
We have seen issues where query engines and event-driven transformations are managed by separate components; in such cases when query engines are stopped (e.g. because of model unloading) the transformation engine gets into an inconsistent state, e.g. the engine stops sending notifications, but the model update listeners are still active. An approach to handle this is to register a ViatraQueryEngineLifecycleListener to the engine, and dispose the transformation on the appropriate events.
This process could be made automatic: we could provide this support in a generic way, allowing transformation developers to use it. The question is what kind of transformations should rely on these. A first idea: