Для GraphTraversalSource
необходимость вызова close()
обусловлена тем, как вы строите объект (например, «gts» в вашем случае). Javadocs на DriverRemoteConnection
объясняет требования для close()
. В вашем конкретном случае вы передаете объект Cluster
, который вы сконструировали, DriverRemoteConnection.using()
, что означает, что вы sh сами будете управлять отключением Cluster
и, следовательно, вызов GraphTraversalSource.close()
закроет только Client
случаи, когда ваш GraphTraversalSource
породил свою работу. Затем вам потребуется самостоятельно вызвать Cluster.close()
, чтобы получить полное упорядоченное завершение работы и освобождение ресурсов.
Поведение для close()
на GraphTraversal
, порожденном от GraphTraversalSource
, немного отличается в зависимости от от того, действительно ли вы удаленный или нет. В вашем случае вы используете удаленный обход и, следовательно, должны вызывать close()
для устранения побочных эффектов на сервере (если обход генерировал какие-либо). Собирает ли ваш сервер побочные эффекты или нет для последующего извлечения, зависит от вашей реализации, но для большей части кода c лучше всего всегда делать это явно. Обратите внимание, что обходы порождаются над базами данных не удаленных (встроенных) графов, которые повторяются до завершения, так что hasNext()
равен false
, вызовет вызов close()
и освободит ресурсы, удерживаемые графом. Например, вызов iterate()
автоматически вызовет close()
.
Как примечание: поддержка сбора побочных эффектов, хранящихся на сервере, была удалена из протокола TinkerPop в 3.5.0, так что беспокойство вызывает уходящий - на серверах просто не будет больше побочных эффектов, хранящихся в памяти для последующего поиска.