[MDSAL-61] Data Broker transactions should expose future which will complete when transaction is commited Created: 13/Nov/14 Updated: 14/Jan/24 Resolved: 14/Jan/24 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding API, DOM API |
| Affects Version/s: | None |
| Fix Version/s: | 13.0.0 |
| Type: | Improvement | ||
| Reporter: | Tony Tkacik | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Description |
|
Current APIs exposes such future, but also submits transaction as side effect, but some use-cases shows, that having that future existing before transaction is submitted could potentially ease development of proper monitoring of transactions. This is also true for TypedTransactions, where the body being executed only sees ReadOperations/WriteOperations, hence cannot actually submit the future – but it may want to hook further processing based on the outcome of the transaction. Hence the future should really be exposed from *Operations interface. |
| Comments |
| Comment by Robert Varga [ 13/Nov/15 ] |
|
Move to MDSAL. |
| Comment by Robert Varga [ 13/Nov/18 ] |
|
Furthermore transaction(chain) allocation should return a FluentFuture, so that implementations do not have to deal with the synchronous returns and users are guided towards event-driven programming. |
| Comment by Robert Varga [ 18/Mar/19 ] |
|
This would be a separate issue. |
| Comment by Robert Varga [ 08/Oct/20 ] |
|
The patch is quite risky as it involves changing future lifecycle. We already have enough risks going with datastore, let's punt his for a release. |