|
|
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Или есть какие-то другие варианты решения проблемы? Да, причем всегда. Думать надо головой а не другими частями тела.[/quot] Какие мы самонадеянные! Говорить-то всегда легко! Короче получается так, что не успевает коллекция из одного потока закрыться, как в нее лезет другой поток и вытаскивает оттуда данные, которые этого другого потока ну никак не касаются. Синхронизировать коллекцию не рекомендуют, так как будут в сервлете "узкие места". Может еще как-то можно обойти проблему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 13:18:37 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Какие мы самонадеянные! Говорить-то всегда легко! Короче получается так, что не успевает коллекция из одного потока закрыться, как в нее лезет другой поток и вытаскивает оттуда данные, которые этого другого потока ну никак не касаются. Синхронизировать коллекцию не рекомендуют, так как будут в сервлете "узкие места". Может еще как-то можно обойти проблему? Зачем коллекция находится в поле? Только чтобы шарить её между методами? Если локальная переменная не подходит, используй ThreadLocal. Ты же код не показываешь и ничего нормально не объясняешь. Какой же помощи можно таким образом получить? Начать хотя бы с того что с обычными коллекциями никак не связан глагол "закрыть" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 13:32:46 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Разные потоки это разные запросы клиентов. Как справедоиво было замечено общая коллекция нужна только в том случае, когда ее данные разделяются (просматриваются и ИЗМЕНЯЮТСЯ) множеством пользователей одновременно. Сегодня предельно ясно, что нельзя использовать перемнные экземпляра сервлета (поля) для сохраннения изменяемой информации. Для этого следует использовать атрибуты запроса или контекст сеанса. Смело создаем для каждого сеанса отдельную коллекцию и, если в конечном требуется итоге слить ее в одну коллекцию, сохраняемую в контексте сервлета (приложения), то делаем это в некоторые дискретные промежутки времени одним потоком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 14:30:39 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4 324f4Или есть какие-то другие варианты решения проблемы? Да, причем всегда. Думать надо головой а не другими частями тела. Какие мы самонадеянные! Говорить-то всегда легко! Короче получается так, что не успевает коллекция из одного потока закрыться, как в нее лезет другой поток и вытаскивает оттуда данные, которые этого другого потока ну никак не касаются. Синхронизировать коллекцию не рекомендуют, так как будут в сервлете "узкие места". Может еще как-то можно обойти проблему?[/quot] заводить какие либо поля в сервлете - это по моему антипаттерн - этого делать не стоит, я бы на вашем месте задумался нужна ли ваабще здесь эта коллекция - которая одна и та же для разных пользователей - если нужна сделайте сервисный метод (не в сервлете) на уровне сервисов или если нету такого уровня то на уровне дао, в котором происходит изменение этой коллекции там синхронизуйте что хотите - а тут никаких полей заводить не надо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2007, 18:47:34 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Привожу на вашу критику фрагмент кода, чтобы было понятно: Код: plaintext 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. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. Объявил все переменные локально, как необходимо. Но не уверен, что будет работать корректно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 08:09:59 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
MBasilРазные потоки это разные запросы клиентов. Как справедоиво было замечено общая коллекция нужна только в том случае, когда ее данные разделяются (просматриваются и ИЗМЕНЯЮТСЯ) множеством пользователей одновременно. Сегодня предельно ясно, что нельзя использовать перемнные экземпляра сервлета (поля) для сохраннения изменяемой информации. Для этого следует использовать атрибуты запроса или контекст сеанса. Смело создаем для каждого сеанса отдельную коллекцию и, если в конечном требуется итоге слить ее в одну коллекцию, сохраняемую в контексте сервлета (приложения), то делаем это в некоторые дискретные промежутки времени одним потоком. Мне как раз не нужно, чтобы коллекция использовалась одновременно всеми пользователями, она не должна быть общей. Мне нужно, чтобы в каждом потоке для каждого пользователя была своя индивидуальная коллекция! Привел фрагмент кода-см.выше. Все переменные объявил локально, а не как поля сервлета. Так что смотрите, критикуйте)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 08:15:33 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4 MBasilРазные потоки это разные запросы клиентов. Как справедоиво было замечено общая коллекция нужна только в том случае, когда ее данные разделяются (просматриваются и ИЗМЕНЯЮТСЯ) множеством пользователей одновременно. Сегодня предельно ясно, что нельзя использовать перемнные экземпляра сервлета (поля) для сохраннения изменяемой информации. Для этого следует использовать атрибуты запроса или контекст сеанса. Смело создаем для каждого сеанса отдельную коллекцию и, если в конечном требуется итоге слить ее в одну коллекцию, сохраняемую в контексте сервлета (приложения), то делаем это в некоторые дискретные промежутки времени одним потоком. Мне как раз не нужно, чтобы коллекция использовалась одновременно всеми пользователями, она не должна быть общей. Мне нужно, чтобы в каждом потоке для каждого пользователя была своя индивидуальная коллекция! Привел фрагмент кода-см.выше. Все переменные объявил локально, а не как поля сервлета. Так что смотрите, критикуйте)) Итак - первое - хочу отметить, что первую свою проблему - вы решили ) все будет работать ) НО! Есть несколько существенных замечаний ) 1) Там где вы формируете sql запрос - есть большая security problem - этот метод формирования запроса позволяет провести sql injection, для решения этой проблемы - я советую более внимательно относится к валидации реквестовых параметров, а еще лучше - использовать Hibernate 2) Не стоит заниматься в сервлете тем что вормировать запросы к бд - это надо делать немного на другом уровне - выделите дао - и там производите доступ - иначе код превращается в лапшу 3) Кроме того код не очень читается - постарайтесь писать переменные - по мере необходимости тоесть сужайте область видимости переменных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 10:43:14 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Мне как раз не нужно, чтобы коллекция использовалась одновременно всеми пользователями, она не должна быть общей. Мне нужно, чтобы в каждом потоке для каждого пользователя была своя индивидуальная коллекция! Привел фрагмент кода-см.выше. Все переменные объявил локально, а не как поля сервлета. Так что смотрите, критикуйте)) Ну а смысл был вообще выносить эту чисто локальную коллекцию из метода и морочить нам мозги? :) Ну в вообще твой код это... что-то... Можно книгу написать не тему "так делать нельзя". Почитай что-ли книжку какую-нибудь, типа Горький вкус Java, Рефакторинг Фаулера... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 10:45:11 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Java Programmer 324f4 MBasilРазные потоки это разные запросы клиентов. Как справедоиво было замечено общая коллекция нужна только в том случае, когда ее данные разделяются (просматриваются и ИЗМЕНЯЮТСЯ) множеством пользователей одновременно. Сегодня предельно ясно, что нельзя использовать перемнные экземпляра сервлета (поля) для сохраннения изменяемой информации. Для этого следует использовать атрибуты запроса или контекст сеанса. Смело создаем для каждого сеанса отдельную коллекцию и, если в конечном требуется итоге слить ее в одну коллекцию, сохраняемую в контексте сервлета (приложения), то делаем это в некоторые дискретные промежутки времени одним потоком. Мне как раз не нужно, чтобы коллекция использовалась одновременно всеми пользователями, она не должна быть общей. Мне нужно, чтобы в каждом потоке для каждого пользователя была своя индивидуальная коллекция! Привел фрагмент кода-см.выше. Все переменные объявил локально, а не как поля сервлета. Так что смотрите, критикуйте)) Итак - первое - хочу отметить, что первую свою проблему - вы решили ) все будет работать ) НО! Есть несколько существенных замечаний ) 1) Там где вы формируете sql запрос - есть большая security problem - этот метод формирования запроса позволяет провести sql injection, для решения этой проблемы - я советую более внимательно относится к валидации реквестовых параметров, а еще лучше - использовать Hibernate 2) Не стоит заниматься в сервлете тем что вормировать запросы к бд - это надо делать немного на другом уровне - выделите дао - и там производите доступ - иначе код превращается в лапшу 3) Кроме того код не очень читается - постарайтесь писать переменные - по мере необходимости тоесть сужайте область видимости переменных Ах да забыл - зачем вам нужен вектор ?? я конечно понимаю что разработчики java сказали что поправили все баги с этим динозавриком ) Но я все же не стал бы использовать здесь вектор, хотя бы потому что он медленнее ArrayList за счет того что он синхронизованный - я думаю не стоит использовать Вектор в ThreadSafe коде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 10:52:47 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Это for (int i = 0; i < zabiv.size(); i++) { rom = (String) zabiv.elementAt(i); } плохо, поскольку медленно, если у Вас версия до 1.5, то так; Iterator iter = zabiv.get(property); while (iter.hasNext()) { rom = (String) iter.next(); } а начиная с 1.5 лучше так: List<String> zabiv = new LinkedList<String>; . . . for( String s : zabiv ) { rom = s; } Действие zabiv.removeAllElements(); вовсе не требуется, поскольку ссылка zabiv на коллекцию выбрасывается в мусор. Однако зачем из коллекции перебрасывать в массив, не лучше ли использовать для обработки непосредственно коллекцию. И вообще, как мягко заметил "Java Programmer" сегодня вообще такое решение недопустимо. Сервлет не должен выполнять запросов в базу. Даже, если Вы не желаете использовать какие-либо оболочки (типа Hibernate, а используете POJO) надо задействовать шаблон DAO и создать дополнительную прослойку в виде службы. Кроме того, там где это возможно, лучше использовать для запросов PreparedStatement при вводе параметров запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 11:27:58 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Извините, опечаточка вышла, конечно : Код: plaintext 1. 2. 3. 4. А кроме того редактор формуа почему-то выбросил мои квадратные скобки с буквой i внутри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2007, 11:34:11 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Сорри за кривые переменные) Просто еще с паскаля привычка осталась объявлять переменные перед непосредственно кодом. Что касается формирования в сервлете запросов к бд - в моем случае это не есть непосредственно запрос к БД (я же в начале говорил, что там есть промежуточный слой). Я использую что-то типа объектно-реляционного преобразования. Это даже не запрос SQL, а запрос на уровне объектов хранилища. Этот запрос DQL, который разбирается на сервере, и там же преобразовывается в запрос SQL. А на будущее конечно буду отделать бизнес-логику от коннекта) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 06:39:16 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Java Programmer Итак - первое - хочу отметить, что первую свою проблему - вы решили ) все будет работать ) НО! То есть при таком раскладе все будет работать корректно и данные коллекций не будут перемешиваться между потоками?? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 12:36:58 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4То есть при таком раскладе все будет работать корректно и данные коллекций не будут перемешиваться между потоками?? ) Конечно. Локальный объект внутри метода создается каждым потоком независимо. Локальные переменные потокобезопасны по определению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:05:40 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
[quot 324f4]Привожу на вашу критику фрагмент кода, чтобы было понятно: а разве в документуме IDfCollection автоматически не научились закрываться?:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:52:46 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
livehacker[quot 324f4]Привожу на вашу критику фрагмент кода, чтобы было понятно: а разве в документуме IDfCollection автоматически не научились закрываться?:) Неа))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 13:56:30 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
kest_ruКонечно. Локальный объект внутри метода создается каждым потоком независимо. Локальные переменные потокобезопасны по определению. Это не совсем правда. Ведь не факт что объект на который ссылается локальная переменная не расшарен в другом потоке. Всё упирается в scope объекта. Где он был создан и где он стал доступным для GC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 14:20:01 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Blazkowicz kest_ruКонечно. Локальный объект внутри метода создается каждым потоком независимо. Локальные переменные потокобезопасны по определению. Это не совсем правда. Ведь не факт что объект на который ссылается локальная переменная не расшарен в другом потоке. Всё упирается в scope объекта. Где он был создан и где он стал доступным для GC. В данном случае он создается внутри метода и никуда передается, так что будет потокобезопасно, хотя в общем замечание справедливо, конечно. Особенно если локальная переменная - ссылка на синглтон :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2007, 22:16:58 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Зашедший Blazkowicz kest_ruКонечно. Локальный объект внутри метода создается каждым потоком независимо. Локальные переменные потокобезопасны по определению. Это не совсем правда. Ведь не факт что объект на который ссылается локальная переменная не расшарен в другом потоке. Всё упирается в scope объекта. Где он был создан и где он стал доступным для GC. В данном случае он создается внутри метода и никуда передается, так что будет потокобезопасно, хотя в общем замечание справедливо, конечно. Особенно если локальная переменная - ссылка на синглтон :) Извините, а сиглтон -это что??? Мелодия в мобильнике?)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2007, 07:04:35 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Извините, а сиглтон -это что??? Мелодия в мобильнике?)) Да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2007, 12:25:27 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Извините, а сиглтон -это что??? Мелодия в мобильнике?)) Суть - музыка (минусовка) записывается в формате MIDI, а сверху накладывается песня. В итоге получаем гораздо меньшей размер, чем у MP3, плюс проигрывания качество обычно выше. Сейчас морально устаревает, т.к. мобильники переходят на новый формат - обсервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2007, 15:37:56 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=34842907&tid=2144431]: |
0ms |
get settings: |
6ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 320ms |
| total: | 440ms |

| 0 / 0 |
