0

I have web application based on jsp and spring mvc where i need resolve this task :

The user must be able to add new instances of the main entity using wizard dialog. The wizard consists of 3 steps:

  1. On the first step there must be a form which allows filling main entity’s fields, including association with the entity related as many-to one (it’s recommended to use drop-down field). The form should contain fields of different types: text, number, date, radio button, etc. Some fields should be required and some are not. Example: input name, surname, birth date, phone, number of kids, select gender (radiobutton), department (drop-down), etc.

  2. On the second step user fills additional attributes, including association with the entity related as many-to-many with the current one. Example: associate employee with skills that (s)he has (checkboxes), add some note (textarea).

  3. On the third step all the fields from previous 2 steps should be displayed as read-only fields. The user should confirm saving this data into database. After the user confirms saving, the data should be saved into database, and user should be redirected to the page with the list of objects.

How can i transfer and hold information without using sessions(Http session, session scope)?

xlecoustillier
  • 16,183
  • 14
  • 60
  • 85
Valerii Rusakov
  • 1,091
  • 2
  • 11
  • 22

1 Answers1

1

You need to keep state across multiple server interactions. There are several possibilities, in general factors such as the size of the state data to be retained influence our decisions.

It sounds like you have some small number of hundreds of bytes here, so you're not particularly constrained by size - a few Megabytes would be more of a challenge.

First possibility, keep it all in the browser in JavaScript variables, no actual need to send anything to server. This is typical of a modern dynamic Web UI, where the server serves up data rather than pages. Sounds like you're in a multi-page world so discount this option.

Second, just put some data (possibly encrypted, in a cookie) effectively the browser is keeping the data for you, but it's shared across the pages.

Third use Http Session state - you case does sound very much like a typical candidate for a session. Why do you want to avoid it? Depending upon your server's capabilities this approach may not give great resilience behaviour (if the state is on one server instance then all requests for a session must be served by the same server). Note that HTTP Session and EJB Session Beans are not the same thing, HttpSessions are lighter weight.

Use a custom session "database" - maybe literally a SQL database maybe something lighter. For larger scale data entry cases, where a user may take 10s of minutes to complete many pages this may be the best option - the user's work is saved should they need to break off and resume later. It's more development work and you need to look at housekeeping too, but it's sometimes the best option.

In summary: be very clear why you reject the "obvious" HTTP session technique, in terms of simplicity it's where I'd start.

djna
  • 54,992
  • 14
  • 74
  • 117
  • It's apart of architecture requirements. This requirement comes from a fact, that modern high-loaded web applications are often deployed on many application servers (forming clusters), and any next web request can be processed by any server different from the server that served the previous request. – Valerii Rusakov Jan 21 '13 at 15:47
  • Right, as it happens some app servers will propagate sessions between instances at the expense of some overhead, and most infrastructures also provide simple session affinity so in practice the pragmatic approach is often just to use Http Sessions. – djna Jan 21 '13 at 16:17