[
https://issues.apache.org/jira/browse/TINKERPOP3-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000938#comment-15000938
]
Zachary Kurey commented on TINKERPOP3-932:
------------------------------------------
I'll just register that I don't have a strong opinion here. Either approach(or
both) seems reasonable. I’d expect most users after canceling are going to
make some changes to their script and re-run it from the beginning, so the
state of the session vars may not matter. I'd hope the script is either
idempotent if re-run, or that the user takes steps to re-establish known good
state prior to re-executing the script.
Whats most intuitive to me personally is that it would be treated the same as
if I had been manually executing the statements, and just canceled the latest
one. Which would mean that I should assume the vars have been affected and
that I should ensure everything is in an expected state before re-running.
> Add ability to cancel script execution associated with a Gremlin Server
> Session
> --------------------------------------------------------------------------------
>
> Key: TINKERPOP3-932
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-932
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.0.2-incubating
> Reporter: Zachary Kurey
> Assignee: stephen mallette
>
> Currently with a {{SessionedClient}} there is no way to cancel a long running
> script and the client has to depend on Gremlin Server side configured
> timeouts before they can execute another script associated with the same
> session id.
> There is a way we can forcefully close a session from the client side, or
> just close the entire Gremlin client. But it would be useful for client side
> applications to be able to cancel script execution, have its intermediate
> effects rolled back, and be able to continue interacting with the session
> without losing session variable state maintained on the Gremlin server side.
> Unsure where this should live at an API level, since canceling by session id
> isn't relevant for all {{Client}} implementations. If somehow when the
> {{CompletableFuture<ResultSet>}} returned by {{Client.submitAsync}} could do
> this when the {{Future}} is canceled, that would be a nice way to bridge
> implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
