diff --git a/spring-session-docs/src/docs/asciidoc/guides/boot-findbyusername.adoc b/spring-session-docs/src/docs/asciidoc/guides/boot-findbyusername.adoc index e9907e14..1b201e22 100644 --- a/spring-session-docs/src/docs/asciidoc/guides/boot-findbyusername.adoc +++ b/spring-session-docs/src/docs/asciidoc/guides/boot-findbyusername.adoc @@ -28,7 +28,7 @@ Consider the following scenario: * User goes to library and authenticates to the application. * User goes home and realizes they forgot to log out. -* User can log in and terminate the session from the library using clues like the location, created time, last accessed time, and so on. +* User can log in and end the session from the library using clues like the location, created time, last accessed time, and so on. Would it not be nice if we could let the user invalidate the session at the library from any device with which they authenticate? This sample demonstrates how this is possible. @@ -145,5 +145,5 @@ You can emulate the flow we discussed in the <> section by doi * Enter the following to log in: ** *Username* _user_ ** *Password* _password_ -* Terminate your original session. +* End your original session. * Refresh the original window and see that you are logged out. diff --git a/spring-session-docs/src/docs/asciidoc/guides/boot-websocket.adoc b/spring-session-docs/src/docs/asciidoc/guides/boot-websocket.adoc index fb0505f7..e4659eab 100644 --- a/spring-session-docs/src/docs/asciidoc/guides/boot-websocket.adoc +++ b/spring-session-docs/src/docs/asciidoc/guides/boot-websocket.adoc @@ -59,14 +59,14 @@ What does `AbstractSessionWebSocketMessageBrokerConfigurer` do behind the scenes * `WebSocketConnectHandlerDecoratorFactory` is added as a `WebSocketHandlerDecoratorFactory` to `WebSocketTransportRegistration`. This ensures a custom `SessionConnectEvent` is fired that contains the `WebSocketSession`. -The `WebSocketSession` is necessary to terminate any WebSocket connections that are still open when a Spring Session is terminated. +The `WebSocketSession` is necessary to end any WebSocket connections that are still open when a Spring Session is ended. * `SessionRepositoryMessageInterceptor` is added as a `HandshakeInterceptor` to every `StompWebSocketEndpointRegistration`. This ensures that the `Session` is added to the WebSocket properties to enable updating the last accessed time. * `SessionRepositoryMessageInterceptor` is added as a `ChannelInterceptor` to our inbound `ChannelRegistration`. This ensures that every time an inbound message is received, that the last accessed time of our Spring Session is updated. * `WebSocketRegistryListener` is created as a Spring bean. This ensures that we have a mapping of all of the `Session` IDs to the corresponding WebSocket connections. -By maintaining this mapping, we can close all the WebSocket connections when a Spring Session (HttpSession) is terminated. +By maintaining this mapping, we can close all the WebSocket connections when a Spring Session (HttpSession) is ended. // end::config[] @@ -131,7 +131,7 @@ You can see that the message is no longer sent. ==== Spring Session expires in 60 seconds, but the notification from Redis is not guaranteed to happen within 60 seconds. To ensure the socket is closed in a reasonable amount of time, Spring Session runs a background task every minute at 00 seconds that forcibly cleans up any expired sessions. -This means you need to wait at most two minutes before the WebSocket connection is terminated. +This means you need to wait at most two minutes before the WebSocket connection is closed. ==== You can now try accessing http://localhost:8080/ diff --git a/spring-session-docs/src/docs/asciidoc/index.adoc b/spring-session-docs/src/docs/asciidoc/index.adoc index f6519589..fb30174b 100644 --- a/spring-session-docs/src/docs/asciidoc/index.adoc +++ b/spring-session-docs/src/docs/asciidoc/index.adoc @@ -1177,8 +1177,8 @@ include::{session-jdbc-main-resources-dir}org/springframework/session/jdbc/schem ==== Transaction Management -All JDBC operations in `JdbcIndexedSessionRepository` are executed in a transactional manner. -Transactions are executed with propagation set to `REQUIRES_NEW` in order to avoid unexpected behavior due to interference with existing transactions (for example, running a `save` operation in a thread that already participates in a read-only transaction). +All JDBC operations in `JdbcIndexedSessionRepository` are performed in a transactional manner. +Transactions are performed with propagation set to `REQUIRES_NEW` in order to avoid unexpected behavior due to interference with existing transactions (for example, running a `save` operation in a thread that already participates in a read-only transaction). [[api-hazelcastindexedsessionrepository]] === Using `HazelcastIndexedSessionRepository`