I'm currently working on an asp.net website.
I have a page (main.aspx) which displays records from a database table. Another page (editing.aspx) is responsible for editing records in the DB table.
let's assume we have a scenario where two users are using the website, user1 (on session1) is viewing the records in main.aspx, user2 (on session2) is editing the DB table from editing.aspx, what I want is: to refresh main.aspx for user1 when user2 saves his changes to the DB table.
I tried using an AJAX timer that pulls the DB for changes every 10 seconds, and refreshes an UpdatePanel (in which I'm displaying the records), and it works just fine, but I want to know if there'se a better way than pulling the DB server for changes.
thanks.
It is debatable if the other way is better but what you are looking for is persistent connection to the server that lets the server send e message to the page. There is a good library for .NET called SignalR that abstracts away the details. It is certainly more network efficient but depending on your use case the update panel may be good enough. Basically with SignalR you will send a message from the server-side code of your edit page which would be received by a JavaScript function on your main page. Then you either show the data or cause a refresh in some way.
Related
We have created a ASP.NET website to give ticket-based support to our customers. Together with our software, we have given a separate VB6 application where customers can send queries to us, and they can see replies, if any. This application loads the ASP.NET page inside a Web Browser control. When customers send queries, it will be added to our database; and we send replies to their questions. So ultimately we will be putting replies in a "reply" column of the table.
I want to show replies to customers as soon as we add them. We have set a timer in our support application which checks whether a reply is present in the database. If so, then we show it. We need to check every 5 minutes that any replies are present in the database. So I think it is what is responsible for more traffic and load on my web server and SQL Server.
Is there any mechanism by which we can trigger the support application which loads the ASP page from the web server? whenever we add a reply to a particular customer, it should be shown to that customer. How this can be done? Are there any better ideas?
How to restrict the page by accessing only one user at a time. Using asp.net can i use global.asax, is there any other way to restrict, if one user accessing the page, another user not able to access that page. we have to give message that one user is accessing the page. is it possible. can you help me or give some reference.
Although there are probably many better ways of dealing with this sort of problem, I'm going to assume that you do actually need this.
What I would do:
Make your application so that when the page is loaded(when it isn't "locked"), it logs to a database that the page was loaded and "lock" it. In the actual page, I'd have some kind of AJAX to constantly poll the web server every 5-15 seconds to tell your application the user is still on the page. And then make it so that the page becomes unlocked after 5-15 seconds from the time saved to the database by the last AJAX call.
Again, I really suspect that there is a better way around an issue like this, but this is a direct answer to your question
Based on this:
yeah sure, jupaol, it is depend on accounts, in my web application, one report has to approve only one user, but the approve authority having two users. if both of them accessing the same page and approve at a time, it will big mess. here i an not using database.
The problem is related with concurrency, there are several ways to face an issue like this, for example the easiest one is to use optimistic concurrency. Even when you are not using a database for this, you can emulate it.
You should be storing the result of the approvers somewhere, in order to mark the report as approved, with this in mind you should be able to do something like this:
Before render the page get the latest report status
If the report has not been approved, render normally
If the report was approved seconds before, render it in read-only mode reporting who approved it (or similar approach)
Add a validation to your ChangeStatus method, in this method do the following:
Get the latest status of the current report
If the report is still not validated, then block the thread (you could use a Mutex or similar) and mark the report as validate it
If the report was already validate it, raise a domain exception and handle it in your page correctly (perhaps render the page in read-only mode explaining that the report was already validate it)
If you want a more responsive application, (RIA), you might want to consider the following approaches:
Perhaps this would be the worst approach but it's still an option, you could keep a log tracking when a user request your page, then in subsequent requests check if the log is still valid, if it is not, then redirect to another page indicating the page is in use, otherwise allow access to the page. I believe this is an error-prone approach because you would be relying on this simple validation in order to prevent an inconsistency in your system, besides you would have the polling problem described in the following approach
Using AJAX to poll data from a service checking if the report has been approved. Perhaps this is the easiest way to accomplish this but it is not recommended it, because you would be polling your server constantly, and eventually you would have scalability problems
You could use Comet to get notified to the browser (client) whenever a server event has occurred, in this case when your report has been approved. The problem with this approach is that you have to keep an opened connection with the server in order to get notified.
The last approach and the most recommended these days is to use Web Sockets, this is the technology used in StackOverflow to get notifications in real time.
For example Zendesk has a feature called Agent Collision Notification - when you edit a ticket you get a note if somebody else its editing this ticket.
What is the Infrastructure to support a feature like this? This question seems to aim at the same thing but at a much lower level.
For the system to be completely dynamic (also notifying the first viewer) and reasonable fast, probably some comet or websocket like stuff is needed. But unlike in chat systems (a prime comet example) in a Ticket system users are constantly switching pages.
What would be the program flow and the server infrastructure for a thing like this?
If you want to allow realtime collaboration then this question that also mentions Operational Transforms will be of interest to you. And there's also a question about operational transformation libraries.
What would be the program flow and the server infrastructure for a thing like this?
I work for Pusher so I can tell you one solution using our technology.
User A opens page where there could be a 'collision'. Within the page subscribe to a channel for the page.
User A starts editing the page. Send an AJAX request to the server so there is some persisted state about the fact the page is being edited. Trigger an event on the channel stating that the user is editing the page.
User B opens the page. The page loads and can display the information from the persisted state that the page is being edited.
User A finishes editing and a request is made to the server to update the page state. Trigger an event indicating that nobody is editing the page. This event will be distributed to User B (the updated page can also be distributed via within the event or via an AJAX request when the event is received).
User B now knows he/she can edit the page. They begin editing (see step 2.) and User A is notified that User B is now editing the page.
It would also be quite cool to use presence so you could see who else was viewing the page and to allow the users to discuss changes as they happen.
We have a window application and a web application, and both connect to a same database to handle data. User on web application will do some changes and wait for the approve from users on window application. Is there any way to show a live update or notification on web application whenever an approve is made at window application which is lead to change in database?
Note: we use ASP.NET for web application and .NET for windows application
This link which talks about SQLDependency and Query Notification seems to be what you are looking for.
You could setup a "notification" area within an updatepanel, or just use straight up ajax to make queries to the database on a specified interval as well.
There are several options.
you can refresh your ASP.NET page by regular interval. http://www.devcurry.com/2009/03/how-to-refresh-aspnet-gridview.html
Refresh a portion of the page periodically using AJAX. I would use jquery for the ajax stuff: jquery.com
Not sure how long the approval process is expected to take, but you could set the page to poll the server every 5 seconds, 15 seconds, whatever makes sense. If it's just refreshing a small portion of the page, it shouldn't be too much of a burden on the server relative to reloading the entire page at every interval.
We have several wizard style form applications on our website where we capture information from the user on each page and then submit to a backend process using a web service.
Unfortunately we can't submit the information in chunks during each form submission so we have to store it the users session until the end of the process and submit it all at the same time.
Is the amount of server memory/sql server disk space the only constraint on how much I can store in users sessions or is there something else I need to consider?
Edit: The site is built on ASP.NET web forms.
Assuming the information is not sensitive then you could store the information in a cookie which would reduce the amount of information required to be stored server side. This would also allow you to access the information via JavaScript.
Alternatively you could use the viewstate to store the information although this can lead to large amounts of data being sent between the server and the client and not my preferred solution.
The amount of session information you should store varies wildly depending on the application, number of expected users, server specification etc. To give a more accurate answer would require more information :)
Finally, assuming that the information collected throughout the process is not required from page to page then you could store all the information in a database table and only store the records unique id in the session. As each page is submitted the db record is updated and then on the final page all the information is retrieved and submitted. This is not an idea solution if you need to retrieve previous information on each subsequent page due to the number of db reads required.
You could also have 1 asp page with the entire html form, and hide parts of it until the user fill and "submits" the visible part...
then simply hide the part that is filled out and show the next part of the form...
This would be extremely easy in the .NET framework, use panels for each "wizard step" and add loggic when to display and hide each panel.
you will then have all the data on one page.
If you use a traditional HTTP model (i.e. don't use runat="server") you can post the data to another asp page and place the posted data into hidden form elements, you can do this for however many pages you need thus avoiding placing anything in a session variable.
Since it is problematic from performance point of view to store large amounts of data in user Session object, ASP.Net provides some other workarounds on top of what is mentioned in the posts above. ASP.NET Profile Provider allows you to persist session related information in a database. You can also use Session State Server which uses a separate server to store all Session information. Both of these situations take into account if you need to use clusters or load balancers, the servers can still recognize the session information across different servers. If you store information in the Http Session object, you run into the problem that one user must always go to the same server for that session.
Session, viewstate, database. These are all slow but will get the job done.
Hidden form fields is the answer I like best.
There are other ways to persist state. Cookies, popup window, frameset or iframes.