[
https://issues.apache.org/jira/browse/TINKERPOP-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068069#comment-15068069
]
stephen mallette commented on TINKERPOP-932:
--------------------------------------------
I was thinking about this one a bit this morning. To summarize all the
discussion to this point, we seemed to converge on:
1. Don't worry about intermediate commits - if users do that, they are on their
own.
2. Not rolling back bindings on a cancel (the more i thought about this today,
the less technically feasible it seemed)
Both of these take a fair bit of complexity off the table. Now we're just
talking about stopping a long run script from executing.
> Add ability to cancel script execution associated with a Gremlin Server
> Session
> --------------------------------------------------------------------------------
>
> Key: TINKERPOP-932
> URL: https://issues.apache.org/jira/browse/TINKERPOP-932
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.0.2-incubating
> Reporter: Zachary Kurey
> Assignee: stephen mallette
> Fix For: 3.1.1-incubating
>
>
> 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)
