Problems of Web application and database access

[opaper]

I must start by saying that I am developing for 10 years on AS400 and me half a year ago when it just somehow allowed the time to occupy myself with J2EE as a hobby. Especially EJBs raise the claim so that developers only have to worry about business logic. Especially for Web applications, which I would lie in the heart (no configuration required on the local client) but this seems not to apply.

Glaring example:

Customer name is displayed in list. Later, should also address will be displayed. However, the program throws LazyInitializationException because Hibernate session exists only for access to customer-DAO. Later, no session is available to load address. In Spring there is for it then the OpenSessionInViewFilter. If that is once installed, it is difficult to eliminate later. Object, for example, customer notice for several requests. Also this filter helps but not if the following happened: customers register, log out again, then back on. Select an order and would like to receive printed confirmation of order. Download and place ads in two different types of request. After sign request is terminated and OpenSessionInViewFilter closes application. When printing customer order confirmation is again detached.

Solution options:

A Hibernate session per session is not possible, since application at faults. Eager-Loading: not allowed. However, one can initialize the object as a compromise in Hibernate, for example Hibernate.initialize (customer.getAdress ()). In a HQL query we then won again the required lazy loading. Only primary key: Save technically you have to talk about it often with database. Lock - Lock method via client is reconnected to Hibernate session. Hibernate Long Session forces: to implement the management of applications transactions. Perhaps the lesser evil!!

You can add the comments as well as doubts about this topic here.!!

[X-Ray]

For concurrent access, I see optimistic locking most appropriate requires the use of a property version. One issue which may of course very important, especially since most multiple database requests are to combine in one transaction. Another problem is the synchronization of requests, because Hibernate session is not thread-safe. Multiple almost simultaneous incoming requests to try the same object from the http session with several Hibernate sessions store. In Spring: SerializeRequestsFilter synchronized incoming requests to an object in the http session. I would be interested now, of course, very, who, with what technology already Web-App. realized with DB connectivity has to the above claim, one need only to concentrate on the business logic is equitably. Provide as Stateful Session Beans in conjunction with JBoss really an adequate solution?

[Shell]

In my experience with Web applications, it is a good rule state as little as possible to keep on the server. I would even say * should * if possible, we keep only the principal / login information in the called session. Maybe the "basket", but that was it ... Everything else belongs to the client, either encoded in URLs or hidden fields in forms. Cookies are problematic because they have not a tab window / state but browser state, and therefore unsuitable for state normal as client. If you do really crazy things (eg RIA) you can save state in javascript or html. But the best ever on the client server and not on the halt. This forces a more entities can load from the backend, optimize it but in the aspects of front end if you are ready.

[Adley]

Actually, the "open session in view" fairly enforced. You open the session in a filter, and reads it there too after the request is processed. The best way to use DI container (for example picocontainer), which MVC Framework is integrated with. (Struts / Webwork). This gives the actions (business logic), the session if the need to and do not take care of the management.