I'm rather new to Spring and I was just wondering if someone would be able to clear something up for me. What I am wondering is what is the scope of a spring mvc web application. Do users get a new instance of the application whenever they use it or is it like a singleton where everyone gets the same instance of the application?
For example, if I am storing some data in a controller that user 1 had accessed, and user 2 comes along and starts using the web application will user 2 see user 1's data or are they entirely separate instances?
I have tried to find an answer to this but with no luck. I have read about the different bean states within an application but haven't found anything about the application itself.
Any insight is greatly appreciated,
HarleyQ14
The Spring MVC application is a singleton. Every user accesses the same application. To do otherwise would be cripplingly bad for performance and scalability.
When you say "I am storing some data in a controller", do you mean storing request- or session-related data in field of the controller object? If so, then the default behaviour of Spring will cause problems for you, since everything is shared.
If you want to have such request- or session-private controller instances, then consider using scoped beans.
Related
I'm designing a new ASP.NET website (ASP.NET is somewhat new to me so forgive stupid questions) and I was wondering about the life time of an object that I would instantiate in the Global.asax's Application_Start event (i.e. new myClass()). I would refer to the object through a static pointer somewhere.
The reason why I was thinking of doing this was to create a master object for the running ASP.NET application that would track some pieces of information per user (browser), even though I'm storing much of the info in my database. In other words, I wanted to use an array of sessions indexed by a user key, and this array would be an element in myClass that, as mentioned above, gets instantiated in the Global.asax's Application_Start event. I'll regularly trim my array to account for users who have gone off or haven't done anything after NN minutes.
Or, is this just nuts because objects instantiated during the application's life are not reliable in terms of lifetime.
Thanks in advance!
Kind regards,
Derek
Why not use the application cache?
Unfortunately, msdn appears to be down right now, but the link is
http://msdn.microsoft.com/en-us/library/system.web.httpcontext.cache.aspx
It is accessible in your asp.net site through the Context property of the current HttpApplication.
Where you create the object doesn't matter, what matters is where you store the reference to the object.
If you put the reference in a static variable, the object will survive as long as the application is running.
Using static variables in a web application can have its uses, but you have to be careful as a web application is multi threaded. If you change any data in the object, you have to synchronise the access to the data, so that only one thread at a time can access it.
I trying to build an ASP.NET MVC application using Nhibernate and Structuremap along with the Repository pattern.
Through my initial approach to this project and the subsequent reading, I was wanting to keep the Nhibernate Session confined to the Repositories, and the Repositories to the Controller. But at the same time, in regards to transactions, I wanted to keep this separated from the repository methods (i.e. I just wanted to call session.Save()).
But It almost seems required that the Controller know about the session so that I can perform any transaction setup on the session before any Controller action, and any persistence to the database after the action using something like (i.e. the ActionFilterAttribute methods BeforeExecution or AfterExecuted, or BeginRequest/EndRequest events in the MvcApplication.
So in my mind I am having to give the current NHibernate Session to the Controller as well as the Repository, just so I can act on the Session when certain actions/results occur on the controller.
Is this the only way I can go about this?
I have read Ayende's blogs, and an assortment of different ways to go about this, but in the case of using the repository pattern, this almost seems like a must. I was hoping to be able to make the Nhibernate / StructureMap setup to the most pluggable way possible so with the exception of defining FluentNhibernate configuration for a specific project, there would be very minimal wiring for adding it to another MVC project.
That's ok. You'll need to open your session on your request begin and close it on your request end.
I'm managing a rather large project, written in asp.net webforms + mvc3, with a large user base, and a pretty high daily visitor count. Basically, there are a lot of requests at any given moment.
One of my controllers in MVC that handles / resizes images on the fly has the following attribute applied to it:
[SessionState(SessionStateBehavior.Disabled)]
Now, if an action in the controller tries to access the session - it obviously throws an exception - so we're good so far.
The problem is: if I go to the IIS Worker Processes window (Win Server 2008 R2, IIS 7.5), and check the current requests for this site, I can sometimes see the requests to an action in this controller. Their current state is locked in State: RequestAcquireState, Module Name: Session. Sometimes these locks go over a second or two in this state.
Wasn't the whole point of the attribute in the first place to make the requests to the controller ignore the state, and not waste time (and possibly being locked) trying to acquire the state?
If this is so - am I doing something wrong here, or does the problem lie elsewhere?
[migrated from comments]
If you're using a custom controller factory or route handler, make sure that they're aware of the controller's session state behavior. Marking a controller as not requiring session state requires cooperation from both of these components. Out-of-box, the DefaultControllerFactory and MvcRouteHandler are designed to work with this. See DefaultControllerFactory.GetControllerSessionBehavior and MvcRouteHandler.GetHttpHandler for more information. If you're writing custom components, you can use those methods as inspiration.
I have two web applications in ASP.NET which are quite the same (same business logic, same DAL, same DB scheme but different instance).
The only thing that I need to change is the design (logo, color,...) and the text (global and local resource) to adress two separate business sector. We cannot "subdomain" the application because we need the two app "seems to be" independant.
Is it a good idea to run only one instance for the 2 web applications.
For example :
I will have 2 hostnames : mycompagny.com and mycompagny2.com and I will put an HTTP Module which will set a string which will be propagated in my application like 'company' and 'company2'. I will instanciate the dal only once but the connection string will change depending on the string 'company' or 'company2'.
Any pros and cons ? Any other alternatives ?
[Updated]
Just for information it is a Multi-Business and Multi-Tenant application because both application will have custom theme for some parts of the application.
For example :
mycompagny.com/Busineess1, mycompagny.com/Busineess2, mycompagny.com/Busineess3,..
and
mycompagny2.com/Busineess2, mycompagny2.com/Busineess2, mycompagny2.com/Busineess3,...
It sounds like you are describing a Multi-Tenant application. Here is a nice overview of some of the challenges of working Multi-Tenant in ASP.Net. There is actually quite a lot of information being produced recently on Multi-Tenant ASP.Net MVC applications, so that is also worth a look.
Yes this is done all the time..even for large sites.
In ASP.NET, you can parse the Request.Url and determine which content to display or which data to retrieve, depending on the domain name.
When you're instantiating the DAL, you'll have to specify which db you want to connect to.
So at each request, you check the Request.Url, instanciate the DAL and then process your ressources ? I thought that you should instantiate the DAL at Application.Start()...
So How and "where" do you set the config to prevent passing the Request.Url string?
I'm a bit worried because instantiate a DAL is a costly process... so is there a future "performance problem" ?
In an effort to understand MVC 2 and attempt to get my company to adopt it as a viable platform for future development, I have been doing a lot of reading lately. Having worked with ASP.NET pretty exclusively for the past few years, I had some catching up to do.
Currently, I understand the repository pattern, models, controllers, data annotations, etc. But there is one thing that is keeping me from completely understanding enough to start work on a reference application.
The first is the Service Layer Pattern. I have read many blog posts and questions here on Stack Overflow, but I still don't completely understand the purpose of this pattern. I watched the entire video series at MVCCentral on the Golf Tracker Application and also looked at the demo code he posted and it looks to me like the service layer is just another wrapper around the repository pattern that doesn't perform any work at all.
I also read this post: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx and it seemed to somewhat answer my question, however, if you are using data annotations to perform your validation, this seems unnecessary.
I have looked for demonstrations, posts, etc. but I can't seem to find anything that simply explains the pattern and gives me compelling evidence to use it.
Can someone please provide me with a 2nd grade (ok, maybe 5th grade) reason to use this pattern, what I would lose if I don't, and what I gain if I do?
In a MVC pattern you have responsibilities separated between the 3 players: Model, View and Controller.
The Model is responsible for doing the business stuff, the View presents the results of the business (providing also input to the business from the user) while the Controller acts like the glue between the Model and the View, separating the inner workings of each from the other.
The Model is usually backed up by a database so you have some DAOs accessing that. Your business does some...well... business and stores or retrieves data in/from the database.
But who coordinates the DAOs? The Controller? No! The Model should.
Enter the Service layer. The Service layer will provide high service to the controller and will manage other (lower level) players (DAOs, other services etc) behind the scenes. It contains the business logic of your app.
What happens if you don't use it?
You will have to put the business logic somewhere and the victim is usually the controller.
If the controller is web centric it will have to receive its input and provide response as HTTP requests, responses. But what if I want to call my app (and get access to the business it provides) from a Windows application which communicates with RPC or some other thing? What then?
Well, you will have to rewrite the controller and make the logic client agnostic. But with the Service layer you already have that. Yyou don't need to rewrite things.
The service layer provides communication with DTOs which are not tied to a specific controller implementation. If the controller (no matter what type of controller) provides the appropriate data (no mater the source) your service layer will do its thing providing a service to the caller and hiding the caller from all responsibilities of the business logic involved.
I have to say I agree with dpb with the above, the wrapper i.e. Service Layer is reusable, mockable, I am currently in the process of including this layer inside my app... here are some of the issues/ requirements I am pondering over (very quickly :p ) that could be off help to youeself...
1. Multiple portals (e.g. Bloggers portal, client portal, internal portal) which will be needed to be accessed by many different users. They all must be separate ASP.NET MVC Applications (an important requirement)
2. Within the apps themselves some calls to the database will be similar, the methods and the way the data is handled from the Repository layer. Without doubt some controllers from each module/ portal will make exactly or an overloaded version of the same call, hence a possible need for a service layer (code to interfaces) which I will then compile in a separate class project.
3.If I create a separate class project for my service layer I may need to do the same for the Data Layer or combine it with the Service Layer and keep the model away from the Web project itself. At least this way as my project grows I can throw out the data access layer (i.e. LinqToSql -> NHibernate), or a team member can without working on any code in any other project. The downside could be they could blow everything up lol...