Can I use sql transactions in web applications?
I.e. when a user starts filling forms the transaction begins. But when another user fills the form at the same time does he get another transaction?
The form is complete when three pages of data are submitted by the user. The data are saved to different tables after filling the specific pages; after completing all form pages the commit should be invoked.
Does this work for a web application where there may be multiple users at same time filling in forms?
I used this method but I get errors that the database/server is not responding/busy.
Is there is any other option to avoid incomplete form submission?
Using a transaction on a forum application is not going to be a good idea, if 2 users are trying to submit new threads at around the same, User 2 would be blocked from accessing/updating tables with the data they are submitting until User 1's transaction is committed.
Related
I have multiple ASP.NET Gridviews on a page, and each has their own Insert/Update/Delete commands.
In order to prevent duplicate DB transactions on page refresh, I am using a Session variable similar to this method here: Example (src: http://aspalliance.com/articleViewer.aspx?aId=687&pId=4)
That works as intended. The problem is that many of our users have multiple tabs open performing actions on different search criteria. If a user runs a transaction on one tab, then switches to another tab, the next transaction they attempt will not commit at all. Since the Session variable has now updated from the other tab, it will prevent the transaction thinking it's a page refresh.
I also cannot redirect to the same URL, as I would lose all search criteria and other form values that need to persist on postback.
Any other tips to have an ASP.NET site running in multiple tabs and also preventing duplicate DB transactions?
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.
I have build a web application which shows the list of customers using datalist control of asp.net , Each customer can be updated, The issue is the application is used by multiple users for instance 5-6 at a time, The problem is when 5 users logged in at a same time they can view the same customer list and can make changes to the same customer at similar time,
Is it possible to restrict user from viewing one customer which is being viewed by other user, for instance if customer 1 is being watched and modified by user 1 then user 2,3,4 will not be able to see customer 1 in their list of customers.
Any assistance or tutorials will be highly appreciated
you have 2 options: pessimistic concurrency or optimistic concurrency.
pessimistic con concurrency locks the entity while the user is viewing it. during this time no one else can access the entity. this works on a small scale, but will quickly become a bottleneck in larger systems.
optimistic concurrency uses a version number. any user can view the data. when changing the data the version number must match, otherwise a change has occurred. then you can notify the user of the change and let them decide to cancel or update. this scales very nicely, but requires a little more work to handle version conflicts.
I have an ASP.NET MVC application, that suffers a horrible affliction. In one of the post methods the user is able to submit an update. This update takes maybe 10 seconds to compute, and impatitient users sometimes click more than once. I belive this is causing a database update race condition, and I don't know what to do. Where should I save the "isUpdating"-variable in order to block such repeat requests? It can't be a webrole instance, since those are independent, and my user may end up on one or the other. Nor can it be the database, because of the race condition. I'm sure there must be a stanard way. I could for example see a scenario where I restrict users to specific webroles. Is that possible, or is there a better way?
In this case it would probably be better to write the information from the user to a queue, then return the page to the user straight away.
Then have a worker role that picks the information out of the queue and updates the database.
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.