весенний контроллер объем и хранение данных сеанса

Question

Я новичок в весенний прицел.

У меня есть код, как следует

@Controller 
    public class PageController extends AbstractController { 

private ABCManager abcManager;// repository singleton bean. 

@Inject 
public PageController(final ABCManager accountDiaryManager){ 
    this.abcManager= abcManager; 
} 

    @RequestMapping(value="/createpage",method=RequestMethod.POST) 
public @ResponseBody Page createPage(@RequestParam(value="viewtype")final String viewtype, final WebRequest request) 
    { 
    final ABC abc= (abc) request.getAttribute(AbstractController.CURRENT_ABC, WebRequest.SCOPE_SESSION); 

     ......... 
     abcManager.createPage(Long.valueOf(abc.getId()), page); 
request.setAttribute("abc", abcManager.getabc(abc.getId()),WebRequest.SCOPE_SESSION); 
} 

Поскольку объект а может меняться несколько раз в течение одного сеанса пользователя, как а являются корневым объектом и содержат древовидную структуру и действие пользователя будет включать в себя изменения в любом месте объекта к югу , Поэтому, когда выполняется редактирование, я сохраняю измененный объект abc внутри запроса, так что последний объект abc доступен каждый раз внутри запроса. этот abc может расти очень большой, и это мое беспокойство. Это хороший способ сделать это?

Я хотел бы знать, если это хорошая практика для написания кода. Это безопасный поток? Какая из лучших альтернативных возможностей.

Answer 1

1. Get/Put to session object не является потокобезопасным. В вашем случае, поскольку вы храните данные, относящиеся к конкретному пользователю в сеансе, это безопасно, если вы не ожидаете, что один и тот же пользователь выполнит несколько действий, которые могут одновременно обновлять сеанс. Сказав это, если вы действительно разрабатываете готовую систему производства, и в этом случае у вас будет несколько серверов приложений, вам нужно подумать о том, какова будет ваша стратегия управления сеансом - вы можете использовать липкий сеанс на веб-сервере (Apache httpd например), чтобы весь запрос, принадлежащий одному сеансу, был перенаправлен на тот же сервер приложений, или вам нужно включить репликацию сеанса между серверами приложений.

2. ABC, растущий очень большой, нуждается в количественном определении. Если вы предполагаете, что он вырастет до 1 МБ, и если вы выделили 2 ГБ оперативной памяти для JVM вашего сервера приложений, и, предположив, что 1 ГБ он свободен для требований к памяти приложения, то вы можете хранить данные до 1000 пользователей. Основываясь на том, сколько параллельных сеансов вы планируете поддерживать, вам нужно будет настроить правильное количество ОЗУ.

3. Если ABC хранит временные данные, такие как данные корзины покупок и которые вы можете потерять во время перезагрузки сервера, тогда ваш подход в порядке. Если вы не хотите потерять данные, вы можете рассмотреть возможность использования систем кэширования или типа значений типа NoSQL (CouchBase, Redis и т. Д.). RDBMS также является вариантом, но это действительно зависит от характера данных, которые вы пытаетесь поддерживать в сеансе, и действительно ли они имеют семантику сеанса или вы просто сохраняете их в сеансе для удобства.