|
|
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Добрый день други! Помогите сервлет-чайнику! В процессе разработки возникли такие вопросы: 1) Как известно, если сервлет (назовем его servlet1) наследует класс SingleThreadModel, то контейнер использует отдельный экземпляр servlet1 для обработки каждого из запросов. Это приведет к тому, что каждый вызов метода service() будет обработан последовательно в своем экземпляре servlet1. Хотел узнать, после отработки метода service() отдельный экземпляр сервлета servlet1 удаляется из контейнера сервлетов или остается? 2) Еще вопрос: Если я синхронизирую метод doPost (см. код) код:public synchronized void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding("UTF-8"); System.out.println(req.getCharacterEncoding()); String xmlString = null; String my = null; ..... ...... } То будет создаваться отдельный экземпляр сервлета для метода doPost? Заранее благодарен! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 12:24:58 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
1). Данная модель запрещена, т.к. сильно снижается производительность. Забудьте о ней. 2). Я думаю, то же не лучшее решение. Такой вопрос - а зачем вам нужно синхронизировать doPost? Наверняка, как-то можно без этого обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 12:29:29 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
1) Зависит от реализации сервера, один из типичных вариантов - контейнер создаст один-единственный экземпляр сервлета и выстроит запросы к нему в очередь. Другой вариант - создание пула инстансов. Какой именно вариант используется в используемом Вами сервере - ответит документация. 2) С чего бы это оно будет создаваться, если сервлет не имплементит SingleThreadModel? Просто опять же обработка запросов будет производиться последовательно, а не параллельно. ЗЫ SingleThreadModel вообще deprecated, так что не надо ее использовать, лучше методы сервлетов писать реентерабельными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 12:30:02 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Leonidv 2). Я думаю, то же не лучшее решение. Такой вопрос - а зачем вам нужно синхронизировать doPost? Наверняка, как-то можно без этого обойтись. Возникла необходимость последовательной обработки метода doPost, так как при параллельных обработках возникают проблемы. В качестве контейнера сервлетов установлен Tomcat 5.0. Пока знаю только такие варианты синхронизации (см. мое сообщение). Если знаете варианты лучше, то пожалуйста подскажите ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 13:00:21 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Возникла необходимость последовательной обработки метода doPost, так как при параллельных обработках возникают проблемы . Вот их и надо решать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 13:07:55 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Возникла необходимость последовательной обработки метода doPost, так как при параллельных обработках возникают проблемы. Ответ никакой. Это и так понятно. Напишите, какие проблемы возникают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 13:16:26 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
В методе doPost создается некая объект-коллекция, которая заполняется значениями из запроса, БД затем закрывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 14:06:15 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4В методе doPost создается некая объект-коллекция, которая заполняется значениями из запроса, БД затем закрывается. И в чем проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 14:14:07 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Blazkowicz 324f4В методе doPost создается некая объект-коллекция, которая заполняется значениями из запроса, БД затем закрывается. И в чем проблема? Видимо, объект-коллекция является полем сервлета... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 14:18:33 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Зашедший Blazkowicz 324f4В методе doPost создается некая объект-коллекция, которая заполняется значениями из запроса, БД затем закрывается. И в чем проблема? Видимо, объект-коллекция является полем сервлета... Либо объект класса Connection :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 14:43:40 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Там используются объекты DFC, (Documenum Fundation Classes). Там дополнительно много всяких надстроек. Могу скинуть фрагмент исходника, если нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 14:53:41 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Там используются объекты DFC, (Documenum Fundation Classes). Там дополнительно много всяких надстроек. Могу скинуть фрагмент исходника, если нужно. А объяснить на словах в чем проблема никак? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 15:25:02 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Проблема в том, что коллекция еще не успела закрыться, а к ней лезет уже другой поток. Еще скажите, чем же синхронизация doPost() вам не по душе? Будет только последовательно он работать. Или же есть еще какие-то предложения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 06:07:08 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Проблема в том, что не успевает коллекция отработать и закрыться, как в не лезет другой поток. Скажите лучше, чем синхронизированный метод doPost() вам не угодил. Ну будет он выполняться последовательно да и только. Или есть какие-то другие варианты решения проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 06:18:36 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Синхронизированный doPost превратит твое приложение в однопользовательскую систему :) Даже при нескольких одновременных пользователях начнутся тормоза. Сделай так чтобы при синхронной работе сервлета проблем не возникало. Ты кстати не рассказал в чем они выражаются? Используется поле сервлета? Это неправильно. Ошибки при доступе к коллекции? Можно использовать синхронизированную коллекцию. Проблема при доступе к содержимому коллекции? Нужно смотреть в чем проблема, и решать ее соответственно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 10:24:30 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4Проблема в том, что не успевает коллекция отработать и закрыться, как в не лезет другой поток. Скажите лучше, чем синхронизированный метод doPost() вам не угодил. Ну будет он выполняться последовательно да и только. Или есть какие-то другие варианты решения проблемы? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 10:34:01 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Kachalov 324f4Проблема в том, что не успевает коллекция отработать и закрыться, как в не лезет другой поток. Скажите лучше, чем синхронизированный метод doPost() вам не угодил. Ну будет он выполняться последовательно да и только. Или есть какие-то другие варианты решения проблемы? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. То есть нужно синхронизировать только объект коллеции? ) Но ведь это тоже приведет к задержке с работой данного объекта. За счет чего увеличится производительность? Ведь все равно потокам нужно будет ждать, пока с коллекцией не отработает уже захвативший коллекцию объект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:19:54 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4То есть нужно синхронизировать только объект коллеции? ) Но ведь это тоже приведет к задержке с работой данного объекта. За счет чего увеличится производительность? Ведь все равно потокам нужно будет ждать, пока с коллекцией не отработает уже захвативший коллекцию объект. - производительность увеличивается за счет того что Вы синхронизируете не метод целиком (со всеми действиями которые в нем описаны и которые возможно вовсе не нуждаются в синхронизации), а только тот объект для которого этого действительно необходимо - кроме того бывают уже синхронизированные коллекции (например Vector) - кроме того можно более разумно писать код (я бы статическую коллекцию заводить не стал) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 11:33:08 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4 Kachalov 324f4Проблема в том, что не успевает коллекция отработать и закрыться, как в не лезет другой поток. Скажите лучше, чем синхронизированный метод doPost() вам не угодил. Ну будет он выполняться последовательно да и только. Или есть какие-то другие варианты решения проблемы? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. То есть нужно синхронизировать только объект коллеции? ) Но ведь это тоже приведет к задержке с работой данного объекта. За счет чего увеличится производительность? Ведь все равно потокам нужно будет ждать, пока с коллекцией не отработает уже захвативший коллекцию объект. Как уже написали - будет синхронизирован только один объект (который может быть нужен не во всех ветках исполнения в методе, к примеру), т.е. в принципе работать таки станет немного быстрее, чем при полной синхронизации, но в общем Вы правы - это не решение. Надо или порождать коллекцию и работать с ней исключительно внутри метода, или, например, создавать пул коллекций, брать свободную, после использования возвращать в пул и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 12:01:12 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
А если придется синхронизировать не один, а несколько объектов?) Еще ведь можно применять wait, notifiAll)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 12:09:31 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
324f4А если придется синхронизировать не один, а несколько объектов?) -для каждого свой блок synchronized 324f4Еще ведь можно применять wait, notifiAll)) - если не очень хорошо знакомы с многопоточным программирование то есть все шансы получить deadlock или не получить никакого эффекта вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 12:17:40 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Может лучше использовать что-нибудь из java.util.concurrent? Например вот это: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CopyOnWriteArrayList.html Или реализовать читателя/писателя. Ведь не локальный список имеет смысл только если из него обращаться из нескольких сервлетов и, скорее всего, как раз по модели читатель/писатель. Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 12:28:20 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Kachalov Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Никогда не понимал - в чем смысл private static?.. От них всегда можно легко избавиться, они создают кучу неудобств, к тому же нафига вообще статические поля в сервлете? 324f4Или есть какие-то другие варианты решения проблемы? Да, причем всегда. Думать надо головой а не другими частями тела. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:35:51 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Timm Kachalov Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Никогда не понимал - в чем смысл private static?.. - блин, см. посты выше, это пример того как быть если уже сделано криво! Kachalov- кроме того можно более разумно писать код (я бы статическую коллекцию заводить не стал) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 13:39:44 |
|
||
|
Вопрос по SingleThreadModel
|
|||
|---|---|---|---|
|
#18+
Timm...От них всегда можно легко избавиться... Не всегда. Например, если используется некий "фреймворк", в котором такая фигня воткнута в базовый класс, а переписать это нельзя (какая-нить ERP). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 14:06:18 |
|
||
|
Вопрос по 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?all=1&fid=59&tid=2144431]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
56ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 331ms |
| total: | 496ms |

| 0 / 0 |
