@@ -246,16 +246,37 @@ public Builder withDefaultAccessMode(AccessMode mode) {
246
246
}
247
247
248
248
/**
249
- * Set the database that the newly created session is going to connect to .
249
+ * Sets target database name for queries executed within session .
250
250
* <p>
251
- * For connecting to servers that support multi-databases,
252
- * it is highly recommended to always set the database explicitly in the {@link SessionConfig} for each session.
253
- * If the database name is not set, then session defaults to connecting to the default database configured in server configuration.
251
+ * This option has no explicit value by default, but it is recommended to set one if the target database is
252
+ * known in advance. This has the benefit of ensuring a consistent target database name throughout the session
253
+ * in a straightforward way and potentially simplifies driver logic as well as reduces network communication
254
+ * resulting in better performance.
254
255
* <p>
255
- * For servers that do not support multi-databases, leave this database value unset. The only database will be used instead.
256
+ * When no explicit name is set, the driver behavior depends on the connection URI scheme supplied to the driver
257
+ * on instantiation and Bolt protocol version.
258
+ * <p>
259
+ * Specifically, the following applies:
260
+ * <ul>
261
+ * <li><b>bolt schemes</b> - queries are dispatched to the server for execution without explicit database name
262
+ * supplied, meaning that the target database name for query execution is determined by the server. It is
263
+ * important to note that the target database may change (even within the same session), for instance if the
264
+ * user's home database is changed on the server.</li>
265
+ * <li><b>neo4j schemes</b> - providing that Bolt protocol version 4.4, which was introduced with Neo4j server
266
+ * 4.4, or above is available, the driver fetches the user's home database name from the server on first query
267
+ * execution within the session and uses the fetched database name explicitly for all queries executed within
268
+ * the session. This ensures that the database name remains consistent within the given session. For instance,
269
+ * if the user's home database name is 'movies' and the server supplies it to the driver upon database name
270
+ * fetching for the session, all queries within that session are executed with the explicit database name
271
+ * 'movies' supplied. Any change to the user’s home database is reflected only in sessions created after such
272
+ * change takes effect. This behavior requires additional network communication. In clustered environments, it
273
+ * is strongly recommended to avoid a single point of failure. For instance, by ensuring that the connection URI
274
+ * resolves to multiple endpoints. For older Bolt protocol versions the behavior is the same as described for
275
+ * the <b>bolt</b> schemes above.</li>
276
+ * </ul>
256
277
*
257
- * @param database the database the session going to connect to. Provided value should not be {@code null}.
258
- * @return this builder.
278
+ * @param database the target database name, must not be {@code null}
279
+ * @return this builder
259
280
*/
260
281
public Builder withDatabase (String database ) {
261
282
requireNonNull (database , "Database name should not be null." );
0 commit comments