MySQL Forums
Forum List  »  InnoDB

Re: transactions and webservers
Posted by: James Day
Date: February 01, 2005 10:02AM

If you're writing this yourself, you might consider not using persistent locks but instead lock and check the data for changes just before saving and tell people if there has been a change since they loaded their view of the data. Release the lock as soon as you complete the save or find out there's been a conflicting change. If you want to you can notify people that someone has "recently" read the same data to give them notice that someone else might change it. This sort of approach often works very well for web applications because there's minimal state information and reads tend to be far more common than writes. Depending on the data, you might find that it's possible to merge successive changes even where two or more saves are involved, or to show the human the two versions and ask them to merge the changes. If that is inappropriate for some operations you might consider timed application (not database) locks to avoid one person going to lunch, going home or having a computer or browser crash locking out everyone else. You can use approaches like periodic refreshes of status frames to tell people of changes in lock state, later saves by others or what others are doing to the data.

Don't even try to get things to the same apache. Instead, store session information in some other way - perhaps in a heap table with primary key returned via a cookie or form on the clients (be sure you code that sort of thing in way which prevents people who send arbitrary keys getting access to the wrong sessions - you'd want to combine the key with the originating IP address and perhaps other information).

Options: ReplyQuote

Written By
January 31, 2005 11:20AM
February 01, 2005 07:39AM
Re: transactions and webservers
February 01, 2005 10:02AM
February 01, 2005 03:03PM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.