

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Optionales Festlegen von Zeitüberschreitungen auf Abfrageebene
<a name="best-practices-gremlin-java-per-query-timeout"></a>

Neptune bietet Ihnen die Möglichkeit, mithilfe der Parametergruppenoption `neptune_query_timeout` (siehe [Parameters](parameters.md)) ein Timeout für Ihre Abfragen einzurichten. Sie können das globale Timeout auch mit folgendem Code überschreiben:

**Anmerkung**  
Die Einstellungen für das Abfrage-Timeout gelten nur für die Auswertung von Abfragen. Bytecode-basierte Transaktionssteuerungsoperationen wie Abfrage-Timeouts `tx().commit()` und `tx().rollback()` unterliegen keinen Abfrage-Timeouts. Weitere Informationen finden Sie unter [Timeout-Verhalten bei Bytecode-Commit und -Rollback](access-graph-gremlin-transactions.md#access-graph-gremlin-transactions-commit-rollback-timeout).

```
  final Cluster cluster = Cluster.build("localhost")
                                 .port(8182)
                                 .maxInProcessPerConnection(32)
                                 .maxSimultaneousUsagePerConnection(32)
                                 .serializer(Serializers.GRAPHBINARY_V1D0)
                                 .create();

  try {
      final GraphTraversalSource g = traversal().withRemote(DriverRemoteConnection.using(cluster));
      List<Object> verticesWithNamePumba = g.with(ARGS_EVAL_TIMEOUT, 500L).V().has("name", "pumba").out("friendOf").id().toList();
      System.out.println(verticesWithNamePumba);
  } finally {
      cluster.close();
  }
```

Für die Übermittlung zeichenfolgebasierter Abfragen würde der Code wie folgt aussehen:

```
  RequestOptions options = RequestOptions.build().timeout(500).create();
  List<Result> result = client.submit("g.V()", options).all().get();
```

Wenn eine Abfrage das Timeout pro Abfrage überschreitet, beendet Neptune sie. Ob Sie eine Abfrage, bei der das Timeout abgelaufen ist, erneut versuchen müssen, hängt von der Art des Fehlers und Ihrer Arbeitslast ab. Anleitungen finden Sie unter [Ausnahmebehandlung und Wiederholungen](transactions-exceptions.md).

**Anmerkung**  
Es können unerwartete Kosten entstehen, wenn Sie den Wert für das Abfrage-Timeout zu hoch festlegen, insbesondere bei einer Serverless-Instance. Ohne eine angemessene Timeout-Einstellung läuft Ihre Abfrage möglicherweise viel länger als erwartet, wodurch Kosten entstehen können, die Sie nie erwartet haben. Dies gilt insbesondere für eine Serverless-Instance, die während der Ausführung der Abfrage auf einen großen, teuren Instance-Typ hochskaliert werden könnte.  
Sie können unerwartete Ausgaben dieser Art vermeiden, indem Sie einen Wert für das Abfrage-Timeout verwenden, der der von Ihnen erwarteten Laufzeit entspricht und nur bei einer ungewöhnlich langen Ausführung zu einer Zeitüberschreitung führt.  
 Ab der Neptune-Engine-Version 1.3.2.0 unterstützt Neptune einen neuen neptune\$1lab\$1mode-Parameter als. `StrictTimeoutValidation` Wenn dieser Parameter den Wert von hat, darf ein Timeout-Wert pro Abfrage`Enabled`, der als Anforderungsoption oder als Abfragehinweis angegeben wurde, den global in der Parametergruppe festgelegten Wert nicht überschreiten. In einem solchen Fall wirft Neptune. `InvalidParameterException`   
 Diese Einstellung kann in einer Antwort auf den Endpunkt '/status' bestätigt werden, wenn der Wert lautet. `Disabled` In der Engine-Version `1.3.2.0` ist `Disabled` der Standardwert dieses Parameters. Ab der Engine-Version `1.4.0.0` ist der `StrictTimeoutValidation` Parameter `Enabled` standardmäßig.   
 Weitere Informationen darüber, wie die Timeout-Priorität bestimmt wird, wenn mehrere Timeout-Einstellungen konfiguriert sind, finden Sie in der Dokumentation zum Parameter [neptune\$1query\$1timeout](parameters.md#parameters-db-cluster-parameters-neptune_query_timeout). 