[ 
https://issues.apache.org/jira/browse/TINKERPOP3-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14980410#comment-14980410
 ] 

Dylan Millikin commented on TINKERPOP3-932:
-------------------------------------------

Ah you're right I didn't think about that case. I was also wondering if what I 
had brought up wasn't already the case when an exception is thrown? For 
instance :

{code}
g.addV()
g.tx().commit()
g.V().stepDoesNotExist()
{code}

Would result in the same behavior right? This in theory could alleviate the 
shortcomings of a cancel feature so long as the cancel is treated like an 
exception?

> 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)

Reply via email to