How to clear the shared objects when user closes the browser abruptly?If the user opens the same application in two tabs, and user tries to close any one of the tab, we have to listen only the closed tab event.
Is there any ways..
It's a bit unclear what you're asking.
If you want to clear something every time the user closes the browser; then why would you want to store that value as a shared object? The purpose of a Shared Object is to persist between sessions, or uses, of the application.
If you're using Shared Object as a generic term to mean some "Stored State" in the flex app; then it will go away at the same time the browser is closed.
If you're using shared object as a generic term to mean some a server side session, then that session should automatically time out on the server, irregardless of what happens in the browser. Most application servers I have used provide a way to execute code when a session timeouts.
Related
Is it normal for some variables not to have been reset and still retain their value
after a page transaction,
and also even after browser was closed but immediately re-opened and same web page re-browsed?
In my VB ASP.NET web app, user performs several steps.
I discovered a bug where after final step, if user refreshes page a couple times,
then closes browser (IE11),
then opens new browser and goes to site,
when Page_load() is called visual basic variables are sometimes not reset, and still have previous value from when page was previously browsed.
It depends on where the state for that variable is tracked.
If the variable is scoped locally to a method, then no it won't still be the same. Once the method is finished, the value is lost.
If the variable is an instance value on an object, it will be retained as long as that object is in memory. Once the object is disposed (usually when no variable references it anymore), the value is lost.
If the variable is static (Shared in VB) then it's scoped to the app domain. It will continue to hold its value as long as the application is running. Once the application exits, the value is lost.
If the variable is kept in session then it will retain its value until the session is ended (either in code, usually by the user logging out, or by the application exiting). Once the session is ended, the value is lost.
If the variable is populated from a cookie then it exists on the client machine and will be supplied to the application any time that client accesses the application. Cookie expiration can be set when creating the cookie, and once it expires the value is lost.
If the variable is populated from some external persistence (such as a database) then it will retain its value until that persistence is changed. The application can shut down, start again, even run on a different machine and the persistence still holds the value.
Look at your variable and determine its scope, that will tell you when it will lose its value.
We know that when we closed the browser, session gets destroy.
Please help me with below query.
Lets say i have clicked on submit button on my registration page and internally it get called SQL store procedure, which takes more time to execute..
on same time if i closed the browse what will happen?
Does my sql connection still available ? if yes then after closing browser still my store procedure is in execute mode?
when exactly the session get destroy?
Would like to know more about this life cycle , Thanks
First have this in mind.
The session is connected with a cookie on the users browser.
The session have a time out.
If anything of this two gone, the session is gone, so let see them analytically.
Cookie
If the cookie is a session cookie (temporary), then is gone when the user close the browser, if its not temporary then is gone when it expires, or of course if the user clears it, or if the user is in private mode is not even saved.
So when the cookie that is connected with the session is gone, you lose the session
The session can be lost even if the browser is not been able to read the session cookie for other reasons.
Session Data on server
The session that is connected with the cookie, is a Dictionary of data that lives on server.
The session have a timeout, so if the user did not update the call to the server inside this time, the server kills the session data on server.
Also, note that the session can be served on the SQL Server, or in a service that runs on background and keeps that data in memory.
If you save the session data on the memory, then they can be lost even before the session times out, from IIS recycle, from the service itself that clears it for their reasons.
Server Side Time Out
If you call a long time function, and the users ends their connection, then the procedure will be continue to runs until either ends either gets a time out. This is not so safe if your process takes 10 minute to execute, you probably gets timeout and never ends correct, even if the user is still connected. If you talk for few seconds, then its relative ok, the procedure will executed even if the users close his browser side.
Check the time out of the page and the time out of the sql server side. If you end well with the user connected, you will end the same and if the user close their connection in the middle.
Have in mind that in a heavy multi user call situation you may have a problem from the session locks, read this q/a ASP.NET Server does not process pages asynchronously
So take care the procedure to not take more than few seconds.
Last words
The most "secure way" to not lost your session in a time period is to use well setup cookie, that is not temporary and keep their life for some months (google keeps their cookie for two years), and use SQL Server to saves your session data.
More details to read at:
ASP.NET State Management Recommendations
Session would not retain values and always return null
Keeping a related ASP.NET application's session alive from another ASP.NET application
ASP.NET Session State Overview
Is it possible to detect in Flex application browser window close event so that an action can be
started when user closes Flex application, does anyone know how to do that if it's possible in the
first place? The reason why i am asking this is because i have a multiuser Flex application where
every user has it's own directory on a server side. Application has logout button which triggers
cleanup of user's directory but what if the user just closes the window? I would like to be able
to lunch that same cleanup upon browser close window
In the page hosting your app, write a Javascript function triggered by window.onbeforeunload, and this function can call a function inside your Flex application.
Note that the onbeforeunload function is not guaranteed to work for all browsers.
I would not recommend that approach because the closing action fails too often, meaning worthless. My browser freezes and force-quitted several times a day. My computer sometimes freezes. My internet connection sometimes dies. I think, some browsers even do not guarantee those kinds of actions executed every time.
So, the session timeout might be one safe way in most cases.
You can also try having a socket connection, so that your server can ping if a user is alive and also can detect if socket is closed. Even socket, however, can be unresponsive or can be disconnected sometimes while user is still using the application.
You might want to be strategic.
I’ve been asked if we can optionally “single-instance” our web portal. See
this post on Hanselman's blog for the same idea in a WinForms app.
Suppose we have 2 shortcuts on the same client machine:
http://MyServer/MyWebPortal/Default.aspx?user=username&document=Foo
http://MyServer/MyWebPortal/Default.aspx?user=username&document=Bar
Clicking on the first shortcut would launch our web portal, log in, and display the document “Foo”. Clicking on the second shortcut should display the document “Bar” in the running instance of the web portal.
My current approach is this: In the Page Load, for the first instance create a per-client Application variable. The second instance looks for the Application variable to see if the portal is running on the client. If it is, the second URL is recorded in another Application variable and the second instance is forcibly exited. I’ve tried creating a ASP.Net AJAX Timer to poll the Application variable for a document to display. This sort of works. In order to respond quickly to the second request I’ve set the Timer interval to 2 seconds. This makes the portal irritating to use because of the frequent postbacks.
Using my approach, is there a way for the second instance to notify the first instance to check the application variable without polling? Is there a better overall approach to this problem?
Thanks in advance
There is no way on the server side to control which browser instance your page opens up on the client. You can't force all requests to open in the same browser window.
Also, an Application scope variable is shared by all users of your application. At least make this a Session-scope variable - otherwise you would only be allowing one user to access your portal at a time!
Honestly this sounds like a silly request from someone who a) probably doesn't understand how these types of things work and b) is trying to do an end-around for users who aren't that bright and actually see a problem with having more than one instance of your portal open.
By default the session expiry seems to be 20 minutes.
Update: I do not want the session to expire until the browser is closed.
Update2: This is my scenario. User logs into site. Plays around the site. Leaves computer to go for a shower (>20 mins ;)). Comes back to computer and should be able to play around. He closes browser, which deletes session cookie. The next time he comes to the site from a new browser instance, he would need to login again.
In PHP I can set session.cookie_lifetime in php.ini to zero to achieve this.
If you want to extend the session beyond 20 minutes, you change the default using the IIS admin or you can set it in the web.config file. For example, to set the timeout to 60 minutes in web.config:
<configuration>
<system.web>
<sessionState timeout="60" />
... other elements omitted ...
</system.web>
... other elements omitted ....
</configuration>
You can do the same for a particular user in code with:
Session.Timeout = 60
Whichever method you choose, you can change the timeout to whatever value you think is reasonable to allow your users to do other things and still maintain their session.
There are downsides of course: for the user, there is the possible security issue of leaving their browser unattended and having it still logged in when someone else starts to use it. For you there is the issue of memory usage on the server - the longer sessions last, the more memory you'll be using at any one time. Whether or not that matters depends on the load on your server.
If you don't want to guesstimate a reasonable extended timeout, you'll need to use one of the other techniques already suggested, requiring some JavaScript running in the browser to ping the server periodically and/or abandon the session when a page is unloaded (provided the user isn't going to another page on your site, of course).
You could set a short session timeout (eg 5 mins) and then get the page to poll the server periodically, either by using Javascript to fire an XmlHttpRequest every 2 minutes, or by having a hidden iframe which points to a page which refreshes itself every 2 minutes.
Once the browser closes, the session would timeout pretty quickly afterwards as there would be nothing to keep it alive.
This is not a new problem, there are several scenarios that must be handled if you want to catch all the ways a session can end, here are general examples of some of them:
The browser instance or tab is closed.
User navigates away from your website using the same browser instance or tab.
The users loses their connection to the internet (this could include power loss to user's computer or any other means).
User walks away from the computer (or in some other way stops interacting with your site).
The server loses power/reboots.
The first two items must be handled by the client sending information to the server, generally you would use javascript to navigate to a logout page that quickly expires the session.
The third and fourth items are normally handled by setting the session state timeout (it can be any amount of time). The amount of time you use is based on finding a value that allows the users to use your site without overwhelming the server. A very rough rule of thumb could be 30 minutes plus or minus 10 minutes. However the appropriate value would probably have to be the subject of another post.
The fifth item is handled based on how you are storing your sessions. Sessions stored in-state will not survive a reboot since they are in the computer's ram. Sessions stored in a db or cookie would survive the reboot. You could handle this as you see fit.
In my limited experience when this issue has come up before, it's been determined that just setting the session timeout to an acceptable value is all that's needed. However it can be done.
This is default. When you have a session, it stores the session in a "Session Cookie", which is automatically deleted when the browser is closed.
If you want to have the session between 2 browser session, you have to set the Cookie.Expired to a date in the feature.
Because the session you talk about is stored by the server, and not the client you can't do what you want.
But consider not using ASP.NET server side session, and instead only rely on cookies.
Unfortunately due to the explicit nature of the web and the fact there is no permanent link between a website server and a users browser it is impossible to tell when a user has closed their browser. There are events and JavaScript which you can implement (e.g. onunload) which you can use to place calls back to the server which in turn could 'kill' a session - Session.Abandon();
You can set the timeout length of a session within the web.config, remember this timeout is based on the time since the last call to the server was placed by the users browser.
Browser timedout did not added.
There's no way to explicitly clear the session if you don't communicate in some way between the client and the server at the point of window closing, so I would expect sending a special URI request to clear the session at the point of receiving a window close message.
My Javascript is not good enough to give you the actual instructions to do that; sorry :(
You cant, as you can't control how the html client response.
Actually why you need to do so? As long as no one can pick up the session to use again, it would expire after that 20 minutes. If resources does matter, set a more aggressive session expiry (most hosting companies did that, which is horribly annoying) or use less objects in session. Try to avoid any kind of object, instead just store the keys for retrieving them, that is a very important design as it helps you to scale your session to a state server when you get big.
Correct me if I am misreading the intent of your question, but the underlying question seems to be less about how to force the session to end when a user closes the browser and more about how to prevent a session from ending until the browser is closed.
I think the real answer to this is to re-evaluate what you are using sessions to do. If you are using them to maintain state, I agree with the other responses that you may be out of luck.
However, a preferred approach is to use a persistent state mechanism with the same scope as the browser session such as a cookie that expires when the browser is closed. That cookie could contain just enough information to re-initiate the session on the server if it has expired since the last request. Combined with a relatively short (5-10 min) session timeout, I think this gives you the best balance between server resource usage and not making the user continually "re-boot" the site.
Oh you have rewritten the question.
That one is absolutely feasible, as long as javascript is alive. Use any timed ajax will do. Check with prototype library http://www.prototypejs.org PeriodicalExecutor or jQuery with the ajax + timer plugin. Setup a dummy page which your executor will call from time to time, so your session is always alive unless if he logouts (kill the ajax timer in the same time) or close browser (which means the executor is killed anyway)