Может мне и не нужен собственно ответ, скорее надо понимание...

Суть такова:
Если юзер логинится и начинает работу с системой(например создаёт какой-нить заказ) - он может пройти по десятку и более страничек за это время... И занести в итоге результат своих ухищрений в БД.

У нас есть сервлеты как классы, есть экземпляры этих сервлетов(которые ложатся под любой поток как вокзальная .... ), есть параметры сессии, которые нас не удовлетворяют как строки и есть БД, в которую не слишком-то хочется заносить данные, в которых сам юзер ещё не уверен.

Теперь ситуация: Создаём, значит, заказ. надо забит ьдля него кучу данных на страничке, подтверждаем что вроде бы правильно всё, потом начинаем создавать линии этого заказа(товар - кол-во. ну и проч атрибуты), потом переходим на создание связей с клиентами и перевозчиками - указываем кто и как учавствует в обработке заказа, ну и напоследок много ещё дополнительной инфы. Потом Юзер вздыхает облегчённо, пробегает по страничкам, просматривает чё он навводил, улыбается и говорит: "поехали". После этого знаменитого слова он вонзает курсор в кнопочку и заказ заносится в таблицы БД с помощью нужных процедур.

Теперь вопрос: Как хранить объект типа Order с набором объектов типа Line в нём и набором объектов Customer и объектов Performer таким образом, чтоб никто другой не залез в него, не занося в БД и не пытаясь втиснуть это всё в сессионные параметры.

Бины, насколько я понимаю, так же не гарантируют супружеской верности потоку.

Пример наобум привёл, интересно знать как это ДОЛЖНО БЫТЬ или РЕКОМЕНДУЕТСЯ ДЕЛАТЬ. Неужели хранение всего в БД, а мелочей - в "кармашках" параметров сессии - это единственная панацея???

У тебя есть :
1. Сесия
2. Скрытые поля
3. Куки

Насколько я знаю нонышним Веб-девелоперам этого хватает

Цитата(KostenkoSergey @ 4.11.2005, 12:02)

У тебя есть : 1. Сесия 2. Скрытые поля 3. Куки Насколько я знаю нонышним Веб-девелоперам этого хватает

МАЛОВАТО БУДЕТ!!!

В конце концов - это стринги, а в моём примере линии и участники обработки заказа желательно организовывать в массивы(эррейлисты и т.д.). Не зря ведь их придумали. А если всю такую информацию запихнуть в сессию - придётся дописывать кусок кода, который будет туда это всё пихать и собирать обратно. Парсер тысызыть своей сессии. Генерить имена параметров типа "ord1line2product1", "ord1line2quantity1". Кажется это уже слишком. Полный абзац.

Не может быть чтоб ничего такого не существовало...

Необязательно то о чём мечтается, может есть другое КРАСИВОЕ решение




Это сообщение отредактировал(а) chief39 - 4.11.2005, 12:47

Цитата(chief39 @ 4.11.2005, 13:41)

Генерить имена параметров типа "ord1line2product1", "ord1line2quantity1"

Я не понял. Зачем? Достаточно будет поместить в сессию один объект User с массивом заказов или чего там нужно.

Цитата(Lamer @ 4.11.2005, 12:56)

Я не понял. Зачем? Достаточно будет поместить в сессию один объект User с массивом заказов или чего там нужно.

Стоп, стоп, стоп... В сессию можно пихать ЛЮБОЙ Object???
Если ДА - то прошу прощения за недочитанную доку

И огромное спасибо.

Сейчас поэкспериментирую

посмотрел я что касается JavaBeans из JSP , вообщем делается это известно как :

Код

<jsp:useBean id="имя экземпляра компонента"> [scope = "page", or "request", or "session", or "application"] класс компонента />

ид определяет имя бина, уникальное в пределах области указанной в скопе.
Сам компонент хранится как атрибут контекста обласи и может быть получен вызовом getAttribute()
так вот теперь о scope :
page - компонент как один из атрибутов PageContext
request - компонент как один из атрибутов ServletRequest
session- компонент как один из атрибутов HttpSession
application-компонент как один из атрибутов ServletContext

тобеж если я не пользуюсь правом на "потупить" объекты тоже можно проносить ...

копать думаю надо тут
Добавлено @ 13:15
так и есть тупил:

Код

request.getSession().setAttribute(String id, Object obj);

а с чего ты взял что только строки ?

chief39, считай, что тебе повезло: твой вопрос решается проще пареной репы.

В атрибутах сессии можно хранить какие угодно объекты - это просто Map. Посмотри сигнатуры методов setAtribute() и getAttribute() в HttpSession.

Поэтому делаешь все в точности так, как ты и написал. Да, и не забываем стереть все из сессии после того как обработка заказа успешно завершилась

Цитата(KostenkoSergey @ 4.11.2005, 13:16)

а с чего ты взял что только строки ?

Спросил у больного здоровье А почему бы и нет? Каждый видит то что хочет видеть. Даже если оно не так. Вбить глупость легче чем выбить, в очередной раз на себе убедился.


Lamer George, огромный спасиб. Настроение на весь день поднялось прям. Попробую репутацией воспользоваться


KostenkoSergey, а это интересная точка зрения Сейчас буду копать.

Кстати,

Код

request.getSession().setAttribute(String id, Object obj);

и

Код

session.setAttribute(String id, Object obj);

сут не одно и тоже? Или есть нюансы?

та то я просто в жбилдере смотрел - и строку те скопировал. одно и тоже.

Цитата(Stampede @ 4.11.2005, 13:27)

В атрибутах сессии можно хранить какие угодно объекты - это просто Map. Посмотри сигнатуры методов setAtribute() и getAttribute() в HttpSession.

Ага... посмотрел на них... уже с другой стороны.
Я ж говорю:


KostenkoSergey интерсное дело говорит... С помощью бинов это тоже реализуется? при скопе размером в сессию.

Хотя, почитаю пока сам. Но и от советов не откажусь

Цитата(chief39 @ 4.11.2005, 14:38)

С помощью бинов это тоже реализуется? при скопе размером в сессию.

Да. Разница, видимо, будет только в том, что к бинам ты сможешь достучаться через jsp'шные теги, а к обычным прикрепленным объектам - только через java-код.

Цитата(Lamer @ 4.11.2005, 15:13)

Да. Разница, видимо, будет только в том, что к бинам ты сможешь достучаться через jsp'шные теги, а к обычным прикрепленным объектам - только через java-код.

А бины "будут мне верны"? ;)
То есть созданный бин будет только в моём потоке/сессии доступен. (Я верно понимаю?)

И.... вопрос до кучи.. Какое соотношение поток/сессия?
Если я коннекчусь к серверу - у меня один поток? Который других не обслуживает?
Может ли у меня быть несколько потоков? То есть одна сессия - несколько потоков.

Ибо в доке всё красиво... но прямых ответов на вопросы "А вот так будет работать?" - маловато

Цитата(chief39 @ 4.11.2005, 20:52)

А бины "будут мне верны"? ;) То есть созданный бин будет только в моём потоке/сессии доступен. (Я верно понимаю?)

Будет только в твоей сессии, все верно.

Цитата(chief39 @ 4.11.2005, 20:52)

И.... вопрос до кучи.. Какое соотношение поток/сессия? Если я коннекчусь к серверу - у меня один поток? Который других не обслуживает? Может ли у меня быть несколько потоков? То есть одна сессия - несколько потоков.

Вот этого спецификация J2EE не определяет. Вопрос, вообще говоря, отдается на откуп производителю. Возможно, что вообще все клиенты обрабатываются одним потоком. У веб-серверов такие прецеденты бывают. Довольно распространенная модификация СУБД Firebird - SuperServer - именно так и работает. Более того, реализация всего в одном потоке обеспечивает чуть более высокую производительность на однопроцессорных машинах. Хотя я сомневаюсь, что хотя бы один сервер приложений J2EE реализован таким образом. Причина проста - множество потоков означает возможность их параллельного выполнения на многопроцессорных системах, следовательно, значительное увеличение производительности.

Разберемся с мыслью "одна сессия - несколько потоков". Если производитель реализует многопоточный сервер, каким образом он может обрабатывать поступающие запросы? Я вижу два варианта:

• все запросы, поступающие от одного и того же клиента, обрабатываются одним потоком сервера
• каждый запрос, не важно от кого он пришел, обрабатывается отдельным потоком

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

Так что, как мне кажется, достаточно учитывать тот факт, что наше приложение многопоточное и применять необходимые способы обеспечения безопасности совместной работы, которые обсуждаются выше в топике "JSP отдельная страничка - отдельный объект?" (почитал, кстати, с немалым удовольствием ), а считать, что на всем протяжении сеанса работы пользователя ему соответствует только одна сессия. Верно и обратное.