Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
L'implémentation openCypher dans Amazon Neptune utilise la sémantique des transactions définie par Neptune. Cependant, les niveaux d'isolement fournis par le pilote Bolt ont des implications spécifiques sur la sémantique des transactions Bolt, comme décrit dans les sections ci-dessous.
Requêtes de transaction Bolt en lecture seule
Les requêtes en lecture seule peuvent être traitées de différentes manières, avec différents modèles de transaction et niveaux d'isolement, comme suit :
Requêtes de transaction implicites en lecture seule
Voici un exemple de transaction implicite en lecture seule :
public void executeReadImplicitTransaction()
{
// end point
final String END_POINT = "(End Point URL)";
// read query
final String READ_QUERY = "MATCH (n) RETURN n limit 10";
// create the driver
final Driver driver = GraphDatabase.driver(END_POINT, AuthTokens.none(),
Config.builder().withEncryption()
.withTrustStrategy(TrustStrategy.trustSystemCertificates())
.build());
// create the session config
SessionConfig sessionConfig = SessionConfig.builder()
.withFetchSize(1000)
.withDefaultAccessMode(AccessMode.READ)
.build();
// run the query as access mode read
driver.session(sessionConfig).readTransaction(new TransactionWork<String>()
{
final StringBuilder resultCollector = new StringBuilder();
@Override
public String execute(final Transaction tx)
{
// execute the query
Result queryResult = tx.run(READ_QUERY);
// Read the result
for (Record record : queryResult.list())
{
for (String key : record.keys())
{
resultCollector.append(key)
.append(":")
.append(record.get(key).asNode().toString());
}
}
return resultCollector.toString();
}
}
);
// close the driver.
driver.close();
}Comme les réplicas en lecture n'acceptent que les requêtes en lecture seule, toutes les requêtes portant sur ces réplicas s'exécutent sous forme de transactions implicites en lecture, quel que soit le mode d'accès défini dans la configuration de session. Neptune évalue les transactions implicites en lecture comme des requêtes en lecture seule selon la sémantique d'isolement SNAPSHOT.
En cas d'échec, les transactions implicites en lecture font par défaut l'objet d'une nouvelle tentative.
Requêtes de transaction de validation automatique en lecture seule
Voici un exemple de transaction de validation automatique en lecture seule :
public void executeAutoCommitTransaction()
{
// end point
final String END_POINT = "(End Point URL)";
// read query
final String READ_QUERY = "MATCH (n) RETURN n limit 10";
// Create the session config.
final SessionConfig sessionConfig = SessionConfig
.builder()
.withFetchSize(1000)
.withDefaultAccessMode(AccessMode.READ)
.build();
// create the driver
final Driver driver = GraphDatabase.driver(END_POINT, AuthTokens.none(),
Config.builder()
.withEncryption()
.withTrustStrategy(TrustStrategy.trustSystemCertificates())
.build());
// result collector
final StringBuilder resultCollector = new StringBuilder();
// create a session
final Session session = driver.session(sessionConfig);
// run the query
final Result queryResult = session.run(READ_QUERY);
for (final Record record : queryResult.list())
{
for (String key : record.keys())
{
resultCollector.append(key)
.append(":")
.append(record.get(key).asNode().toString());
}
}
// close the session
session.close();
// close the driver
driver.close();
}Si le mode d'accès est défini sur READ dans la configuration de session, Neptune évalue les requêtes de transaction de validation automatique comme des requêtes en lecture seule selon une sémantique d'isolement SNAPSHOT. Notez que les réplicas en lecture n'acceptent que les requêtes en lecture seule.
Si vous ne transmettez pas de configuration de session, les requêtes de validation automatique sont traitées par défaut avec un isolement des requêtes de mutation. Il est donc important de transmettre une configuration de session qui définit explicitement le mode d'accès sur READ.
En cas d'échec, les requêtes de validation automatique en lecture seule ne font pas l'objet d'une nouvelle tentative.
Requêtes de transaction explicites en lecture seule
Voici un exemple de transaction explicite en lecture seule :
public void executeReadExplicitTransaction()
{
// end point
final String END_POINT = "(End Point URL)";
// read query
final String READ_QUERY = "MATCH (n) RETURN n limit 10";
// Create the session config.
final SessionConfig sessionConfig = SessionConfig
.builder()
.withFetchSize(1000)
.withDefaultAccessMode(AccessMode.READ)
.build();
// create the driver
final Driver driver = GraphDatabase.driver(END_POINT, AuthTokens.none(),
Config.builder()
.withEncryption()
.withTrustStrategy(TrustStrategy.trustSystemCertificates())
.build());
// result collector
final StringBuilder resultCollector = new StringBuilder();
// create a session
final Session session = driver.session(sessionConfig);
// begin transaction
final Transaction tx = session.beginTransaction();
// run the query on transaction
final List<Record> list = tx.run(READ_QUERY).list();
// read the result
for (final Record record : list)
{
for (String key : record.keys())
{
resultCollector
.append(key)
.append(":")
.append(record.get(key).asNode().toString());
}
}
// commit the transaction and for rollback we can use beginTransaction.rollback();
tx.commit();
// close the driver
driver.close();
}Si le mode d'accès est défini sur READ dans la configuration de session, Neptune évalue les transactions explicites en lecture seule comme des requêtes en lecture seule selon une sémantique d'isolement SNAPSHOT. Notez que les réplicas en lecture n'acceptent que les requêtes en lecture seule.
Si vous ne transmettez pas de configuration de session, les transactions explicites en lecture seule sont traitées par défaut avec un isolement des requêtes de mutation. Il est donc important de transmettre une configuration de session qui définit explicitement le mode d'accès sur READ.
En cas d'échec, les requêtes explicites en lecture seule font par défaut l'objet d'une nouvelle tentative.
Requêtes de transaction de mutation Bolt
Comme pour les requêtes en lecture seule, les requêtes de mutation peuvent être traitées de différentes manières, avec différents modèles de transaction et niveaux d'isolement, comme suit :
Requêtes de transaction de mutation implicites
Voici un exemple de transaction de mutation implicite :
public void executeWriteImplicitTransaction()
{
// end point
final String END_POINT = "(End Point URL)";
// create node with label as label and properties.
final String WRITE_QUERY = "CREATE (n:label {name : 'foo'})";
// Read the vertex created with label as label.
final String READ_QUERY = "MATCH (n:label) RETURN n";
// create the driver
final Driver driver = GraphDatabase.driver(END_POINT, AuthTokens.none(),
Config.builder()
.withEncryption()
.withTrustStrategy(TrustStrategy.trustSystemCertificates())
.build());
// create the session config
SessionConfig sessionConfig = SessionConfig
.builder()
.withFetchSize(1000)
.withDefaultAccessMode(AccessMode.WRITE)
.build();
final StringBuilder resultCollector = new StringBuilder();
// run the query as access mode write
driver.session(sessionConfig).writeTransaction(new TransactionWork<String>()
{
@Override
public String execute(final Transaction tx)
{
// execute the write query and consume the result.
tx.run(WRITE_QUERY).consume();
// read the vertex written in the same transaction
final List<Record> list = tx.run(READ_QUERY).list();
// read the result
for (final Record record : list)
{
for (String key : record.keys())
{
resultCollector
.append(key)
.append(":")
.append(record.get(key).asNode().toString());
}
}
return resultCollector.toString();
}
}); // at the end, the transaction is automatically committed.
// close the driver.
driver.close();
}Les lectures effectuées dans le cadre des requêtes de mutation sont exécutées avec un isolement READ COMMITTED avec les garanties habituelles applicables aux transactions de mutation Neptune.
Que vous transmettiez spécifiquement ou non une configuration de session, la transaction est toujours traitée comme une transaction d'écriture.
Pour les conflits, voir Résolution des conflits à l'aide de délais d'attente de verrouillage.
Requêtes de transaction de mutation à validation automatique
Les requêtes de validation automatique des mutations héritent du même comportement que les transactions implicites de mutation.
Si vous ne transmettez pas de configuration de session, la transaction est traitée comme une transaction d'écriture par défaut.
En cas d'échec, les requêtes de validation automatique des mutations ne font pas automatiquement l'objet de nouvelles tentatives.
Requêtes de transaction de mutation explicites
Voici un exemple de transaction de mutation explicite :
public void executeWriteExplicitTransaction()
{
// end point
final String END_POINT = "(End Point URL)";
// create node with label as label and properties.
final String WRITE_QUERY = "CREATE (n:label {name : 'foo'})";
// Read the vertex created with label as label.
final String READ_QUERY = "MATCH (n:label) RETURN n";
// create the driver
final Driver driver = GraphDatabase.driver(END_POINT, AuthTokens.none(),
Config.builder()
.withEncryption()
.withTrustStrategy(TrustStrategy.trustSystemCertificates())
.build());
// create the session config
SessionConfig sessionConfig = SessionConfig
.builder()
.withFetchSize(1000)
.withDefaultAccessMode(AccessMode.WRITE)
.build();
final StringBuilder resultCollector = new StringBuilder();
final Session session = driver.session(sessionConfig);
// run the query as access mode write
final Transaction tx = driver.session(sessionConfig).beginTransaction();
// execute the write query and consume the result.
tx.run(WRITE_QUERY).consume();
// read the result from the previous write query in a same transaction.
final List<Record> list = tx.run(READ_QUERY).list();
// read the result
for (final Record record : list)
{
for (String key : record.keys())
{
resultCollector
.append(key)
.append(":")
.append(record.get(key).asNode().toString());
}
}
// commit the transaction and for rollback we can use tx.rollback();
tx.commit();
// close the session
session.close();
// close the driver.
driver.close();
}Les requêtes de mutation explicites héritent du même comportement que les transactions de mutation implicites.
Si vous ne transmettez pas de configuration de session, la transaction est traitée comme une transaction d'écriture par défaut.
Pour les conflits, voir Résolution des conflits à l'aide de délais d'attente de verrouillage.
