|
|
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
такая ситуация, логика работы с DB находиться в ejb @Stateless бинах например, Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. .. где Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. все работает, но иногда при множестве запросах от кучи клинетов заканчиваются курсоры в оракле, выставил connection-leak-timeout-in-seconds="10" statement-timeout-in-seconds="6" statement-leak-timeout-in-seconds="2" в логах иногда проскакивает [ Код: java 1. 2. а это и есть Код: java 1. вижу два варианта, сразу закрывать connection после каждого PreparedStatement или CallableStatement, а бин будет жить дальше, и при его повторном вызове, он опять будет брать connection из пула, или выставить у ejb pool idle timeout = 1 sec например, по умолчанию 600, то есть ejb бин живет 10 мин и только потом в нем срабатывает Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... как мне кажется плюсы того что бин живет 10 мин и не отдает connection в пул, в том что при его вызовах в пределах эти 10 мин он не берет connection из пула, а сразу вынимает из него PreparedStatement или CallableStatement, это видно по логам. вобщем какая тут best practice ? спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 14:25:32 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
breathсразу закрывать connection после каждого PreparedStatement или CallableStatement, а бин будет жить дальше, и при его повторном вызове, он опять будет брать connection из пула ... вобщем какая тут best practice ? Ну, сами же всё знаете. Нефиг серверу без дела занимать ресурсы БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 14:35:30 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
вариант просто выставить в админке ejb pool idle timeout = 1 вместо ejb pool idle timeout = 600 не очень ? получается лучше бину жить подольше, и брать/класть connection в pool, чем уничтожаться и создаваться контейнером ? (в этом случае просто переписывать ничего не нужно, все и так находиться в @PostConstruct, @PreDestroy у AbstractDB) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 14:54:39 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
breathвариант просто выставить в админке ejb pool idle timeout = 1 вместо ejb pool idle timeout = 600 не очень ? получается лучше бину жить подольше, и брать/класть connection в pool, чем уничтожаться и создаваться контейнером ? (в этом случае просто переписывать ничего не нужно, все и так находиться в @PostConstruct, @PreDestroy у AbstractDB) Ну, это уже нужно смотреть на ваши нагрузки, померять. Но есть сомнения, что это будет сильно лучше. Т.е. если у бинов есть какая-то логика помимо JDBC, они могут вообще безболезнено отдавать соединения на это время. Кроме этого, бины могут просто вместе работать, обслуживая клинтов чуть дольше (каждого, но при этом более эффективно всех вместе. Короткий idle time к чему приведёт? Бины всегда будут намного чаще пересоздаваться? Скорее всего увеличится нагрузка на GC. Кроме этого не понятно сколько вообще стоит создание-дестрой. Вдруг оно тоже не так дешево обходится. Даже почти наверняка, это же EJB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 15:01:22 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
на сколько знаю, ejb бины не создаются и не удаляются как обычные объекты, они находятся в пуле, и после уничтожения помещаются туда, а по требованию клиента вынимаются от туда, то есть GC тут отдыхает как бы. один из моментов, который нравиться в них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 15:08:31 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
breathна сколько знаю, ejb бины не создаются и не удаляются как обычные объекты, они находятся в пуле, и после уничтожения помещаются туда, а по требованию клиента вынимаются от туда, то есть GC тут отдыхает как бы. один из моментов, который нравиться в них. Да, но короткий idle timeout, который вы предлагаете приведёт к частому пересозданию вместо пулирования. Разве нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 15:11:42 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
>Т.е. если у бинов есть какая-то логика помимо JDBC, они могут вообще безболезнено отдавать соединения на это время. у бинов для работы с DB больше никакой логики нет, но есть бины с другим функционалом - RESTful Web Services @Path("document") @Stateless public class DocumentService extends BaseHttpService { ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 15:11:47 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
BlazkowiczДа, но короткий idle timeout, который вы предлагаете приведёт к частому пересозданию вместо пулирования. Разве нет? не знаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 15:15:29 |
|
||
|
glassfish 3, ejb3 pool idle timeout (пул ejb бинов)
|
|||
|---|---|---|---|
|
#18+
breathне знаю А кто должен знать? Вы же предлагаете такое решение. Pool Idle Timeout : the maximum time that a stateless session bean, entity bean, or message-driven bean is allowed to be idle in the pool. After this time, the bean is destroyed if the bean in case is a stateless session bean or a message driver bean. This is a hint to server. The default value is 600 seconds. The corresponding EJB deployment descriptor attribute is pool-idle-timeout-in-seconds. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2013, 15:19:53 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38151388&tid=2129982]: |
0ms |
get settings: |
10ms |
get forum list: |
24ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
48ms |
get topic data: |
20ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 268ms |
| total: | 450ms |

| 0 / 0 |
