Пожалуйста, добавьте width:100%
к диаграмме контейнера.
Надеюсь, что это решит overflow:hidden
связанную с этим проблему.
classname{min-height:450px;width: 100%;}
может быть, вы можете посмотреть ' терракота ». это структура кэширования, которая может кэшировать сеансы и запускается на отдельном сервере
В WebSphere есть два основных способа репликации данных сеанса:
Какой из них подходит для ваших нужд, сильно зависит в сценарии вашего приложения:
Насколько важна постоянство данных сеанса, когда все серверы приложений выходят из строя? Сколько объектов сеансов у вас одновременно есть в любой момент времени?
В БД вы можете хранить много сеансов без особых проблем, другой вариант всегда заключается в том, сколько памяти доступно.
Я бы выбрал база данных, если она у вас уже настроена, которую в любом случае используют все серверы приложений.
Вот ссылка на WebSphere Information Center с необходимой информацией.
Одно из очевидных решений - включить кластеризацию серверов приложений. Я полагаю, судя по тому, как вы сформулировали свой вопрос, вы отклонили этот вариант. Другой вариант - изменить маршрутизацию, используемую веб-серверами, чтобы использовать привязку сеанса (запросы для одного и того же сеанса отправляются на один и тот же сервер приложений).
Кроме того, я бы повторил ответ dertoni.
There are two options for clustering within WebSphere, session replication or database. If you have large session objects you are best off using database because it allows you to offload stale sessions to disk. If they are then represented then they can be extracted from the database, if you use session replication then those sessions need to stay in memory on not just your target server but also the other servers in the replication group. With large sessions this can lead to an out of memory condition.
With database session handling it is also very customisable and doesn't performance noticeably in the environments that I have used it.