Java 8 はサポートが終了しており、2026 年 1 月 31 日に
非推奨になります。非推奨になると、過去に組織のポリシーを使用して以前のランタイムのデプロイを再度有効にしていた場合でも、Java 8 アプリケーションをデプロイできなくなります。既存の Java 8 アプリケーションは、
非推奨になる日付以降も引き続き実行され、トラフィックを受信します。
サポートされている最新バージョンの Java に移行することをおすすめします。
Datastore クエリのデータ整合性
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
データ整合性レベル
Datastore のクエリでは、次の 2 つの整合性レベルのいずれかで結果を返すことができます。
- 強整合クエリは、結果が最新であることが保証されますが、完了までに時間がかかる場合があります。
- 結果整合性クエリは、一般的により高速に実行されます。ただし、最新ではない結果が返される場合があります。
結果整合クエリでは、結果の収集に使用されるインデックスも、結果整合性に基づいてアクセスされます。その結果、元のクエリ条件と一致しなくなったエンティティが返される場合があります。一方、強整合クエリでは常にトランザクション上の整合性が維持されます。
Datastore クエリのデータ整合性
クエリでは各クエリの特性に基づき、異なる整合性レベルを保証した結果が返されます。
- 祖先クエリ(1 つのエンティティ グループ内のクエリ)は、デフォルトでは強整合性ですが、Datastore の読み取りポリシーを設定することで(後述)、結果整合性にできます。
- 非祖先クエリは常に結果整合になります。
キーによるエンティティの取得(「キーによる検索」とも呼ばれる)は強整合になります。
Datastore の読み取りポリシーの設定
パフォーマンスを向上させるために、すべての読み取りとクエリが結果整合になるように、Datastore の読み取りポリシーを設定できます(API を使用して強整合性のポリシーを明示的に設定することもできますが、現実的な効果はありません。これは、ポリシーに関係なく、非祖先クエリは常に結果整合になるためです)。
Datastore の呼び出し期限
を設定し、Datastore から結果が返されるのを待機する時間の最大値(秒)を指定することもできます。この時間が経過するとアプリケーションは処理を中止し、エラーを返します。期限のデフォルト値は 60 秒です。現時点ではデフォルト値を超える値は設定できませんが、デフォルトより短い値に設定することは可能です。これにより、特定のオペレーションが失敗と判定されるまでの時間を短くできます(ユーザーへのレスポンスの迅速化などの目的に利用できます)。
Java で Datastore の読み取りポリシーを設定するには、ネストされたヘルパークラス
DatastoreServiceConfig.Builder
を使用して Datastore サービス構成
(
DatastoreServiceConfig
)を作成し、クラス
ReadPolicy
のインスタンスに渡します。次の例は、読み取りポリシー、呼び出し期限、またはその両方を設定する方法を示しています。
次のステップ
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-09-04 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eThis API supports first-generation runtimes and is relevant when upgrading to second-generation runtimes, while migration to Java 11/17 requires a separate migration guide.\u003c/p\u003e\n"],["\u003cp\u003eDatastore queries offer two consistency levels: strongly consistent queries, which guarantee the freshest results but may be slower, and eventually consistent queries, which are generally faster but may return stale results.\u003c/p\u003e\n"],["\u003cp\u003eAncestor queries are strongly consistent by default but can be set to eventually consistent, while non-ancestor queries are always eventually consistent.\u003c/p\u003e\n"],["\u003cp\u003eThe Datastore read policy can be set to eventually consistent to improve performance, and the call deadline can be adjusted to control the maximum wait time for a Datastore operation.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can use the \u003ccode\u003eDatastoreServiceConfig\u003c/code\u003e to set the read policy and/or the call deadline for Datastore operations, using the \u003ccode\u003eReadPolicy\u003c/code\u003e for consistency and \u003ccode\u003ewithDeadline\u003c/code\u003e for the time limit, and can use the \u003ccode\u003eDatastoreServiceFactory\u003c/code\u003e to get a \u003ccode\u003eDatastoreService\u003c/code\u003e instance with the desired configuration.\u003c/p\u003e\n"]]],[],null,["# Data Consistency in Datastore Queries\n\n| This API is supported for first-generation runtimes and can be used when [upgrading to corresponding second-generation runtimes](/appengine/docs/standard/\n| java-gen2\n|\n| /services/access). If you are updating to the App Engine Java 11/17 runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/java-differences) to learn about your migration options for legacy bundled services.\n\nData consistency levels\n-----------------------\n\nDatastore queries can deliver their results at either of two consistency\nlevels:\n\n- [*Strongly consistent*](https://en.wikipedia.org/wiki/Strong_consistency) queries guarantee the freshest results, but may take longer to complete.\n- [*Eventually consistent*](https://en.wikipedia.org/wiki/Eventual_consistency) queries generally run faster, but may occasionally return stale results.\n\nIn an eventually consistent query, the indexes used to gather the results are also accessed with eventual consistency. Consequently, such queries may sometimes return entities that no longer match the original query criteria, while strongly consistent queries are always transactionally consistent.\n\nDatastore query data consistency\n--------------------------------\n\nQueries return their results with different levels of consistency guarantee, depending on the nature of the query:\n\n- [Ancestor queries](/appengine/docs/legacy/standard/java/datastore/queries#ancestor_queries) (those within an [entity group](/appengine/docs/legacy/standard/java/datastore/entities#Ancestor_paths)) are strongly consistent by default, but can instead be made eventually consistent by setting the Datastore read policy (see below).\n- Non-ancestor queries are always eventually consistent.\n\nFetching an entity by key, which is also called \"lookup by key\", is strongly\nconsistent.\n\n\u003cbr /\u003e\n\nSetting the Datastore read policy\n---------------------------------\n\nTo improve performance, you can set the Datastore *read policy* so that all reads and queries are eventually consistent. (The API also allows you to explicitly set a strong consistency policy, but this setting will have no practical effect, since non-ancestor queries are always eventually consistent regardless of policy.)\nYou can also set the Datastore *call deadline* , which is the maximum time, in seconds, that the application will wait for Datastore to return a result before aborting with an error. The default deadline is 60 seconds; it is not currently possible to set it higher, but you can adjust it downward to ensure that a particular operation fails quickly (for instance, to return a faster response to the user).\n\n\u003cbr /\u003e\n\nTo set the Datastore read policy in Java, you construct a *Datastore service configuration* ([`DatastoreServiceConfig`](/appengine/docs/legacy/standard/java/javadoc/com/google/appengine/api/datastore/DatastoreServiceConfig)), using the nested helper class [`DatastoreServiceConfig.Builder`](/appengine/docs/legacy/standard/java/javadoc/com/google/appengine/api/datastore/DatastoreServiceConfig.Builder), and pass it an instance of class [`ReadPolicy`](/appengine/docs/legacy/standard/java/javadoc/com/google/appengine/api/datastore/ReadPolicy). The following example shows how to set the read policy, the call deadline, or both:\n\n\u003cbr /\u003e\n\n double deadline = 5.0;\n\n // Construct a read policy for eventual consistency\n ReadPolicy policy = new ReadPolicy(ReadPolicy.Consistency.EVENTUAL);\n\n // Set the read policy\n DatastoreServiceConfig eventuallyConsistentConfig =\n DatastoreServiceConfig.Builder.withReadPolicy(policy);\n\n // Set the call deadline\n DatastoreServiceConfig deadlineConfig = DatastoreServiceConfig.Builder.withDeadline(deadline);\n\n // Set both the read policy and the call deadline\n DatastoreServiceConfig datastoreConfig =\n DatastoreServiceConfig.Builder.withReadPolicy(policy).deadline(deadline);\n\n // Get Datastore service with the given configuration\n DatastoreService datastore = DatastoreServiceFactory.getDatastoreService(datastoreConfig);\n\nWhat's next?\n------------\n\n- [Learn how to specify what a query returns and further control query results](/appengine/docs/legacy/standard/java/datastore/retrieving-query-results).\n- Learn the [common restrictions](/appengine/docs/legacy/standard/java/datastore/query-restrictions) for queries on Datastore.\n- Learn about [query cursors](/appengine/docs/legacy/standard/java/datastore/query-cursors), which allow an application to retrieve a query's results in convenient batches.\n- Learn the [basic syntax and structure of queries](/appengine/docs/legacy/standard/java/datastore/queries) for Datastore."]]