[
https://issues.apache.org/jira/browse/TINKERPOP3-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14980312#comment-14980312
]
stephen mallette commented on TINKERPOP3-932:
---------------------------------------------
> I don't think there's a way to reliably bring the state back to what it was
> before the script was executed?
I guess you could store bindings before the script execution outside of the
scriptengine??? On cancel you could blow out whatever was in the scriptengine
and replace it with the state from the stored bindings...maybe that would
work..............the bigger problem is intermediate commits. Someone decides
to bust this:
{code}
g.addV()
g.tx().commit()
g.V()
{code}
If the script cancels after evaluation of the {{commit()}} we can't revert that
state.....
> off the top of your head, does close terminate the script execution?
it looks like it does an orderly shutdown. it would queue the auto-rollbacks
behind any remaining scripts. The scripts would either timeout or complete and
then auto-rollback and then dead session.
> 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)
