[
https://issues.apache.org/jira/browse/TINKERPOP-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15494443#comment-15494443
]
ASF GitHub Bot commented on TINKERPOP-1442:
-------------------------------------------
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/413
I'm just going to throw my $0.02 out there. Maybe I don't understand the
use case, but this seems strange and unexpected to me. I don't understand why
or how a completely separate client would affect another. Isn't one of the
reasons for using sessions is that a client can come in and out while retaining
state? How would a client safely disconnect and reconnect later without
killing the session and other clients?
> Killing session should make better attempt to cleanup
> -----------------------------------------------------
>
> Key: TINKERPOP-1442
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1442
> Project: TinkerPop
> Issue Type: Bug
> Components: server
> Affects Versions: 3.1.4
> Reporter: stephen mallette
> Assignee: stephen mallette
> Fix For: 3.1.5
>
>
> When a session is killed it tries to rollback transactions prior to ending
> the session. If there is a long-run script (or perhaps a queue of jobs) then
> this close job just gets added to the queue. If that rollback job never
> executes then the transaction gets orphaned.
> Graph implementations tend to have their own methods for cleaning up these
> lingering transactions, but it would be better if the shutdown could occur in
> an orderly fashion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
