I know that Session is for a single user , and application is for multi user purpose.The Data in the application object is shared. Right? Then how can access the application data from an another client.
if My concept is wrong then what's right?
A client cannot access directly from the Application object. The server will need to send data to the client (the way to do this will depend entirely on your scenario). The Application is the same as a static dictionary only that it is thread safe.
for fist one answer application object means not only for single user .the enter in application is just like a data base it will store the data we are given and new user will access on not is only user option.
Related
I am learning Servlet. But don't understand the major difference between HttpSession object and HttpContext object ? As both are used to keep track of the user. But I don't understand , are both of them being accessible across the user or servlet ?
Can anyone provide me an example for this, so I can have clear understanding of it...
Request - Normally used for passing data from jsp to your servlet when you submit the form. When you get redirected to another jsp, your request dies. ie: this attribute lives per user request.please note that http is stateless protocol.so the server will treat every http request as a new request.
Session -session object is basically used to store the values in the session.the data will be preserved until the user terminates the program or closes the browser.Good example will be for storing user credentials. once user is authenticated, Sometimes you may want to check if the user has right access to do on some database operations like add/delete/edit. Once user closes the browser or the session goes idle for x amount minutes (depending on your server setup), the session dies and all info in it will be gone.
Context -context object can be used for multiple users and across multiple browsers.
If it is application specific, consider using context.
If it is user specific, consider using session.
If it is request specific (ex: jsp form submission), consider using request.
Hope this helps.
I am in a situation where requirement is to keep an application level object in web api which can be accessed by all requests. I know one can use HttpContext.Current but that is not required since HttpContext is only for the liftime of request. I need a solution where i can keep an object that all requests can access and update as required.
Use a static class to hold your application level objects. static classes and static data members are created once for the application lifetime and all ASP.NET requests can access them.
I learnt it the hard way. Some time back, I mistakenly created a static field to hold customer-specific database connection string, in a ASP.NET Web API project and it became a mess. On each customer's login it was being set (overridden) in the code and the requests from the previously logged customers were using this newly set static SQL connection string for their queries. It was an embarrassing situation when customer's inadvertently saw each other's data.
You could use SessionState (per session).
I.e.
Session["YourDataKey"] = ApplicationLevelObject;
And then check the session state variable on each request that requires it.
However if you require the object for longer, I.e. every single user session, then I would suggest persisting your object to a database. You could use an ORM such as Entity Framework.
Cheers
I was looking through an old project and wanted to see if anyone had a suggestion on how to hide certain methods from being called by various layers. This was a 3 tier project, webapplication -> web service -> database
In the application there is a User object for example. When a User was being updated, the webapplication would create a User object and pass it to the webservice. The webservice would use the DataAccessLayer to save the User object to the database. After looking at this I was wondering if instead I should have made a Save method in the User class. This way the service and simply call the Save on the User object which would trigger the db update.
However doing it this way would expose the Save to be called from the webapplication as well, correct? Since the webapplication also has access to the same User object.
Is there anyway around this, or is it better to avoid this altogether?
There is a separation of concerns by keepeing the User object as object that only holds data with no logic in it. you better keep it separated for the following reasons:
As you stated, it is a bad practice since the Save' functionality will be exposed to other places/classes where it is irrelevant for them (This is an important for programming generally).
Modifying the service layer - I guess you are using WCF web service as you can transfer a .NET object (c#/VB) to the service via SOAP. If you put the saving logic in the 'User' object, you can't replace it another webservice that receives a simple textual data structures like JSON or XML or simply doesn't support .NET objects.
Modifying the data storage layer - If you want, for example, to store the data inside a different place like other database such as MongoDB, RavenDB, Redis or what ever you want, you will have to reimplement each class that responsible for updating the data. This is also relevant for Unit Testing and Mocking, making them more complicated to interrogate.
I am creating the session in class file of the first application and need to access the same session in second application both of the applications are presented in the same solution.
when i am trying to do this session in second application getting null but session contain data in the first application.
In first Application
System.Web.HttpContext.Current.Session["key1"] = "a";
In second application
if (HttpContext.Current.Session["key1"]!= null) //i am getting session as null hear
How is it possible to send the session data from one application to another application with in the same solution?
please some one help me..
maybe the question is wrong but here is what i want to achieve maybe there is other way to do that.
I have ASP.NET application running .net 3.5, there is a client list and few others List based objects that are shared among all users of application. ie. when client logged in his userID and few other properties are saved within some List in Application state. Problem is that this application is heavy and it's application pool needs to be restarted once a day or so so all the information saved in these List objects is lost. While client personal data which is saved in Out-of-Proc mode on external server is saved.
Is there any way to workaround it ? Shared Session? Something like that.
PLEASE NO MSSQL SOLUTIONS...
Cheers, pros !!!!
Have you looked at caching the lists of data?
This SO article has some good detials.
You should only use Application State as a cache for data persisted elsewhere. You would then use Application_Start or some Lazy loading wrapper class to retrieve such persisted data into the application object.
If you are storing volatile data not persisted elsewhere in the application object then you are in trouble. Hopefully you would have abstracted access to the application object behind some wrapper object so that all your code is accessing the wrapper not tha application object. Now you would need to ensure the modifications are saved elsewhere so that they can be recovered on restart.
To be frank the Application state object is really an aid in porting ASP-Classic sites. Since you should really just treat the application state as a cache, there is an overlap in functionality between it and the ASP.NET Cache object.