Spring 4 @Service с @RequestScope

Question

Чтобы оптимизировать sql-запрос, я сделал службу, которая объединяет другие сервисы, чтобы избежать ненужных вызовов. (Некоторые страницы моего веб-приложение называется миллионы раз в день, поэтому я хочу, чтобы повторно использовать результаты запросов базы данных столько раз, сколько возможно по каждому запросу)

Решение создать этот один:

Мои служба @RequestScope вместо рамки по умолчанию (Singleton)

В MyService

@Service 
@RequestScope 
public MyService { 

private int param; 

@Autowired 
private OtherService otherService; 

@Autowired 
private OtherService2 otherService2; 

private List<Elements> elements; 

private List<OtherElements> otherElements; 

public void init(int param) { 
    this.param = param; 
} 

public List<Elements> getElements() { 

    if(this.elements == null) { 
     //Init elements 
     this.elements = otherService.getElements(param); 
    } 

    return this.elements; 

} 

public List<OtherElements> getOtherElements() { 

    if(this.otherElements == null) { 
     //Init otherElements 
     this.otherElements = otherService2.getOtherElements(param); 
    } 

    return this.otherElements; 

} 

public String getMainTextPres() { 

    //Need to use lElements; 
    List<Elements> elts = this.getElements(); 

    .... 

    return myString; 

} 

public String getSecondTextPres() { 

    //Need to use lElements; 
    List<Elements> elts = this.getElements(); 
    //Also Need to use lElements; 
    List<OtherElements> otherElts = this.getOtherElements();   

    .... 

    return myString; 

} 
} 

В мой контроллер:

public class myController { 
@Autowired MyService myService; 

@RequestMapping... 
public ModelAndView myFunction(int param) { 
myService.init(param); 

String mainTextPres = myService.getMainTextPres(); 

String secondTextPres = myService.getSecondTextPres(); 

} 

@OtherRequestMapping... 
public ModelAndView myFunction(int param) { 
myService.init(param); 

String secondTextPres = myService.getSecondTextPres(); 

} 
} 

Конечно, я упростил свой пример, потому что использование MYSERVICE много других элементов, и я защищать инициализацию членов его атрибутов

Этот метод имеет то преимущество, что делает отложенную загрузку атрибутов только тогда, когда я нужно их. Если где-то в моем проекте (в том же или другом контроллере) мне нужен только SecondTextPres, тогда вызов «getSecondTextPres» будет инициализировать оба списка, которые не имеют места в моем примере, потому что первый список был инициализирован при вызове «getMainTextPres».

Мой вопрос являются:

• Что вы думаете об этом способ делать вещи?
• Могу ли я иметь проблемы с производительностью, потому что я выполняю свою службу по каждому запросу?

Большое спасибо!

Julien

Answer 1

Я думаю, что ваша идея не собирается летать. Я называю тот же или другой контроллер, это будет другой запрос - в этом случае будет создан новый bean-элемент (элементы и другие элементы снова пустуют).

Вы думали о кешировании? Весна имеет хорошую поддержку, где вы можете определить срок действия кеша и т. Д.

Answer 2

Не совсем ясно, что именно вы хотите оптимизировать для создания экземпляра службы в области запроса? Если вы беспокоитесь о печати стопки памяти, вы можете легко измерить ее с помощью JMX или VisualVM.

С другой стороны, вы можете сделать все служебные вызовы чистыми, то есть в зависимости от параметров функции и (ofc) состояния базы данных, и создать экземпляр службы с областью по умолчанию в качестве Singleton.

Это решение позволит вам сэкономить разумное количество ресурсов, так как вы не создадите экземпляр возможного графа объектов на каждом вызове и не будете требовать, чтобы GC очистил предмет после выполнения запроса.

Правило большого пальца состоит в том, чтобы думать, почему именно вам нужен конкретный класс, созданный при каждом вызове, и если он не поддерживает какое-либо состояние для вызова, сделайте его Singleton.

Говоря о ленивой загрузке, он всегда помогает думать о худшем случае, повторенном как 100 раз. Будет ли это действительно сэкономить вам что-то по сравнению с загрузкой один раз и для всего срока службы контейнера.