As classes de requisição são utilizadas pelo Weblogic Server para requisitar Threads para atender às requisições. Ajudando a garantir a prioridade das atividades que requerem muita prioridade, executando primeiro uma atividade de alta prioridade, mesmo que uma atividade de baixa prioridade seja submetida antes.
Classes de requisição (Request Classes) definem o melhor esforço. Elas não garantem que a relação entre as configurações sejam mantidas de forma consistente, pois existem muitos fatores que podem limitar a atuação das classes, mas haverá sempre uma tendência de mate-los. Fatores que podem causar diferenças na relação que foi configurada:
· A mistura de requisições realizadas por diferentes classes na fila de trabalho, em qualquer momento particular. Por exemplo, data uma quantidade de requisições configuradas, pode ocorre de serem executadas mais requisições de baixa prioridade do que as de maiores, em casos onde há muito poucas requisições, então o acabam sendo executadas mais tarefas de baixa prioridade;
· Uma configuração baseada em tempo de execução pode não ser respeitada, pois enquanto uma atividade que consome muito tempo é executada, uma imensa quantidade de tarefas curtas pode estar em execução, muito além do que foi configurado.
Existem muito tipos de classes, cada uma com um conjunto distinto de configuração. Um gerenciador de trabalho pode configurar apenas uma classe de requisição. Entre elas:
Exemplo: existem dois módulos, A e B, o módulo A é configurado em 80 e o módulo B em 20. Durante um período com demanda suficiente, veremos uma distribuição das alocações da threads de 80% para o módulo A e para 20% para o módulo B.
Dica: o valor deste parâmetro não é porcentual, mas sim uma relação, ou seja, se você configurar 400 para o módulo A e 100 para o módulo B, teremos os mesmo 80% para o módulo A e 20% para o módulo B.
Por exemplo: se o módulo A é configurado para 2000ms e o módulo B para 5000ms. Se o tempo de execução da thread está abaixo do valor estipulado, durante um período de carga significativa, e não havendo tempo de espera entre a requisição e a reposta, então será mantido uma proporção de 2:5. Ou seja, se o módulo A está levando em média 1000ms, então o módulo B ficará em 2500ms. O inverso é verdadeiro, se o tempo configurado não puder ser atingido, então haverá um aumento, mas a proporção 2:5 será mantida.
Se houver uma configuração mista de fair-share-request-class e response-time-request-class, esta ultima terá precedência em relação à primeira.
artigo ainda sendo escrito, terá mais logo logo.
Exemplo: esta classe será atribuída às requisições com base nos valores das propriedades do assunto (Subjects) e regras (Roles) das requisições.
<work-manager>
<name>context_workmanager</name>
<context-request-class>
<name>test_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>
Quem não estiver priorizado, usuário ou grupo, terá suas requisições priorizadas pelos valores padrão.
Resumo: De uma forma geral podemos entender os itens acima assim: