Between the lines article on blogging: " For the most part, self assembling communities of bloggers hold a kind of virtual Socratic court, sorting out the issues of the day in a public forum, open to anyone, including spammers."
Could it be that these are some reasons for merger?
Now , back from the commercial break.
The Action classes are singleton classes that are instantiated once per class type per JVM, and all requests for a specific action are routed through the same Action class instance. This IBM article states this well:
"Struts will create a single instance of the Action and allow multiple threads to invoke execute(). This allows for faster request processing, as the framework is not continually creating new Action instances to handle each request. But because a single object is shared between multiple threads, you must observe proper threading considerations, as other threads are likely to pummel instance variables that hold state in the action. "
" Write code for a multi-threaded environment – Our controller servlet creates only one instance of your Action class, and uses this one instance to service all requests. Thus, you need to write thread-safe Action classes. Follow the same guidelines you would use to write thread-safe Servlets. Here are two general guidelines that will help you write scalable, thread-safe Action classes:
Only Use Local Variables – The most important principle that aids in thread-safe coding is to use only local variables, not instance variables, in your Action class. Local variables are created on a stack that is assigned (by your JVM) to each request thread, so there is no need to worry about sharing them. An Action can be factored into several local methods, so long as all variables needed are passed as method parameters. This assures thread safety, as the JVM handles such variables internally using the call stack which is associated with a single Thread.
Conserve Resources – As a general rule, allocating scarce resources and keeping them across requests from the same user (in the user’s session) can cause scalability problems. For example, if your application uses JDBC and you allocate a separate JDBC connection for every user, you are probably going to run in some scalability issues when your site suddenly shows up on Slashdot. You should strive to use pools and release resources (such as database connections) prior to forwarding control to the appropriate View component — even if a bean method you have called throws an exception.
Don’t throw it, catch it! – Ever used a commercial website only to have a stack trace or exception thrown in your face after you’ve already typed in your credit card number and clicked the purchase button? Let’s just say it doesn’t inspire confidence. Now is your chance to deal with these application errors – in the Action class. If your application specific code throws expections you should catch these exceptions in your Action class, log them in your application’s log (servlet.log("Error message", exception)) and return the appropriate ActionForward.
It is wise to avoid creating lengthy and complex Action classes. If you start to embed too much logic in the Action class itself, you will begin to find the Action class hard to understand, maintain, and impossible to reuse. Rather than creating overly complex Action classes, it is generally a good practice to move most of the persistence, and "business logic" to a separate application layer. When an Action class becomes lengthy and procedural, it may be a good time to refactor your application architecture and move some of this logic to another conceptual layer; otherwise, you may be left with an inflexible application which can only be accessed in a web-application environment. The framework should be viewed as simply the foundation for implementing MVC in your applications. Struts Action Framework provides a useful control layer, but it is not a fully featured platform for building MVC applications, soup to nuts. "
Lastly, note that :
"actions are cached, they must be thread-safe. That does’t mean that you can’t use instance variables. If those instance variables are thread safe, and the objects they reference are thread-safe, then everything is good. Servlets suffer the same problem because Servlets are pooled by the container. By default Spring delivers singletons. As long as the services are thread-safe (as all singletons should be), there is no danger."
For session managment, there are two schools of thought: cookie-based / URL rewriting .
cookie based: a message (cookie) containing user’s information is sent to the browser by the Web server. This cookie is sent back to the server when the user tries to access certain pages. By sending back the cookie, the server is able to identify the user and retrieves the user’s session from the session database; thus, maintaining the user’s session.
URL rewriting: all links that are returned to the browser or that get redirected have the session ID appended to them. When the user clicks these links, the rewritten form of the URL is sent to the server as part of the client’s request. The servlet engine recognizes the session ID in the URL and saves it for obtaining the proper object for this user. To use URL rewriting, HTML files cannot be used for links. To use URL rewriting, JSP files must be used for display purposes.
Alternatively, the session object hides the details of dealing with the cookies or rewriting URLS.