You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/src/main/asciidoc/userguide/chapters/pc/PersistenceContext.adoc
+14-85Lines changed: 14 additions & 85 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -187,102 +187,31 @@ If you want to load multiple entities by providing their identifiers, calling th
187
187
but also inefficient.
188
188
189
189
While the Jakarta Persistence standard does not support retrieving multiple entities at once, other than running a JPQL or Criteria API query,
190
-
Hibernate offers this functionality via the
191
-
https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/Session.html#byMultipleIds-java.lang.Class-[`byMultipleIds` method] of the Hibernate `Session`.
which you can use to customize the multi-load request.
196
-
197
-
The `MultiIdentifierLoadAccess` interface provides several methods which you can use to
198
-
change the behavior of the multi-load call:
199
-
200
-
`enableOrderedReturn(boolean enabled)`::
201
-
This setting controls whether the returned `List` is ordered and positional in relation to the
202
-
incoming ids. If enabled (the default), the return `List` is ordered and
203
-
positional relative to the incoming ids. In other words, a request to
204
-
`multiLoad([2,1,3])` will return `[Entity#2, Entity#1, Entity#3]`.
205
-
+
206
-
An important distinction is made here in regards to the handling of
207
-
unknown entities depending on this "ordered return" setting.
208
-
If enabled, a null is inserted into the `List` at the proper position(s).
209
-
If disabled, the nulls are not put into the return List.
210
-
+
211
-
In other words, consumers of the returned ordered List would need to be able to handle null elements.
212
-
`enableSessionCheck(boolean enabled)`::
213
-
This setting, which is disabled by default, tells Hibernate to check the first-level cache (a.k.a `Session` or Persistence Context) first and, if the entity is found and already managed by the Hibernate `Session`, the cached entity will be added to the returned `List`, therefore skipping it from being fetched via the multi-load query.
This setting instructs Hibernate if the multi-load operation is allowed to return entities that were deleted by the current Persistence Context. A deleted entity is one which has been passed to this
216
-
`Session.delete` or `Session.remove` method, but the `Session` was not flushed yet, meaning that the
217
-
associated row was not deleted in the database table.
218
-
+
219
-
The default behavior is to handle them as null in the return (see `enableOrderedReturn`).
220
-
When enabled, the result set will contain deleted entities.
221
-
When disabled (which is the default behavior), deleted entities are not included in the returning `List`.
222
-
`with(LockOptions lockOptions)`::
223
-
This setting allows you to pass a given
224
-
https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/LockOptions.html[`LockOptions`] mode to the multi-load query.
strategy so that we can load entities from the second-level cache, therefore skipping the cached entities from being fetched via the multi-load query.
229
-
`withBatchSize(int batchSize)`::
230
-
This setting allows you to specify a batch size for loading the entities (e.g. how many at a time).
231
-
+
232
-
The default is to use a batch sizing strategy defined by the `Dialect.getDefaultBatchLoadSizingStrategy()` method.
233
-
+
234
-
Any greater-than-one value here will override that default behavior.
235
-
`with(RootGraph<T> graph)`::
236
-
The `RootGraph` is a Hibernate extension to the Jakarta Persistence `EntityGraph` contract,
237
-
and this method allows you to pass a specific `RootGraph` to the multi-load query
238
-
so that it can fetch additional relationships of the current loading entity.
190
+
Hibernate offers this functionality via the `Session#findMultiple` methods which accepts a list of identifiers to load and a group of options which control certain behaviors of the loading -
191
+
192
+
* `ReadOnlyMode` - whether the entities loaded should be marked as read-only.
193
+
* `LockMode` (`LockModeType`) - a lock mode to be applied
194
+
* `Timeout` - if a pessimistic lock mode is used, a timeout to allow
195
+
* `Locking.Scope` (PessimisticLockScope`) - if a pessimistic lock mode is used, what scope should it be applied
196
+
* `Locking.FollowOn` - allow (or not) Hibernate to acquire locks through additional queries if needed
197
+
* `CacheMode` (`CacheStoreMode` / `CacheRetrieveMode`) - how second level caching should be used, if at all
198
+
* `BatchSize` - how many identifiers should be loaded from the database at once
199
+
* `SessionChecking` - whether to look into the persistence context to check entity state
200
+
* `IncludeRemovals` - if `SessionChecking` is enabled, how removed entities should be handled
201
+
* `OrderedReturn` - whether the results should be ordered according to the order of the passed identifiers
239
202
240
203
Now, assuming we have 3 `Person` entities in the database, we can load all of them with a single call
241
204
as illustrated by the following example:
242
205
243
206
[[tag::pc-by-multiple-ids-example]]
244
-
.Loading multiple entities using the `byMultipleIds()` Hibernate API
207
+
.Loading multiple entities using the `findMultiple()` Hibernate API
Notice that only one SQL SELECT statement was executed since the second call uses the
259
-
https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/MultiIdentifierLoadAccess.html#enableSessionCheck-boolean-[`enableSessionCheck`] method of the `MultiIdentifierLoadAccess`
260
-
to instruct Hibernate to skip entities that are already loaded in the current Persistence Context.
261
-
262
-
If the entities are not available in the current Persistence Context but they could be loaded from the second-level cache, you can use the
263
-
https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/MultiIdentifierLoadAccess.html#with-org.hibernate.CacheMode-[`with(CacheMode)`] method of the `MultiIdentifierLoadAccess` object.
In the example above, we first make sure that we clear the second-level cache to demonstrate that
275
-
the multi-load query will put the returning entities into the second-level cache.
276
-
277
-
After executing the first `byMultipleIds` call, Hibernate is going to fetch the requested entities,
278
-
and as illustrated by the `getSecondLevelCachePutCount` method call, 3 entities were indeed added to the
279
-
shared cache.
280
-
281
-
Afterward, when executing the second `byMultipleIds` call for the same entities in a new Hibernate `Session`,
282
-
we set the
283
-
https://docs.jboss.org/hibernate/orm/{majorMinorVersion}/javadocs/org/hibernate/CacheMode.html#NORMAL[`CacheMode.NORMAL`] second-level cache mode so that entities are going to be returned from the second-level cache.
284
-
285
-
The `getSecondLevelCacheHitCount` statistics method returns 3 this time, since the 3 entities were loaded from the second-level cache, and, as illustrated by `sqlStatementInterceptor.getSqlQueries()`, no multi-load SELECT statement was executed this time.
0 commit comments