Languages :: PHP :: Simultaenous connections, Data integrity and Mysql |
|||
| By: omuyelijah |
Date: 23/04/2008 19:35:03 |
Points: 20 | Status: Answered Quality : Good |
|
Hello All, I recently developed a web application using php-mysql (PHP 5 and MYSQL 5) and it works well having to connect to it from other laptops over wireless; SERVER is a laptop too. But this is my concern and I need both help and advice: Its possible from the design that one or more users are able to request update on THESAME cell, THESAME table and I'm afraid that when clients start to use the web application, data integrity will be at question and a concern. Can MySQL handle simultaenous connections of this nature? If it can't, is there a software I need to use on the server to help co-ordinate simultaenous requests, or can I do it from my PHP code (may be multithreading so that some requests are blocked until others are done)? Secondly, I often experience this error of THE WEB PAGE HAS EXPIRED, YOU MIGHT NEED TO DOWNLOAD A LOCAL COPY OF THE REQUESTED PAGE FROM THE SERVER when on a .php page, I try to go back. Now I have to use links back to the previous page to avoid this error. How may it be overcomed? INFO ---- SERVER PC CONFIGURATION: WIN XP SP2, 760Mb RAM, 40Gb HDD, 1.46Ghz Celeron M Processor. CLIENT PC(S) CONFIGURATION: WIN XP/WIN VISTA I only allow about 8 clients in all. Thanks in advance. |
|||
| By: VGR | Date: 23/04/2008 21:14:49 | Type : Comment |
|
| 1) yes, mysqld, as any decent RDBMS, provides data integrity mechanism. Namely, in your case, LOCKs. You can always explicitly BEGIN TRANSACTION and then COMMIT/ROLLBACK, but AFAIK you don't have to. Let it be. When a user opens the table with an UPDATE, the people that would read (SELECT) from the same cell (row) are blocked while the update runs. It's normal and nominal. If ever you experience people trying to UPDATE the same data at roughly the same moment,it may mean you will have truble. One of the two will not retrieve what he has written. You've some solutions to this : you can SELECT... FOR UPDATE; or you can BEGIN TRANSACTION, select, update, commit. IMHO, this is overkill, but you never know... 2) it's a cacheing problem. Check your HTTP headers. The problem occurs more frequently with internet exploder too ("bugs inside" © ;-)) I would recommend NOT to press "back". You should pREVENT peopel from doing back when the history(-1) page is the submlission of POSTed data, for instance... So my recommendations are : a)Always redirect after a successful POST of data. b)And use a decent browser. c)And set the correct cache-control (and such) headers. regards |
|||
| By: omuyelijah | Date: 25/04/2008 16:52:19 | Type : Comment |
|
| Hello VGR, Thanks 4 ur reply. I'll get back as soon as I try it out. regards. |
|||
| By: omuyelijah | Date: 05/05/2008 17:02:33 | Type : Comment |
|
| Hello VGR, It worked. Simultaenous connections r handled well by mysqld.exe while the PHP + MySQL combination is doing well. I had no need for using LOCKS. Thanks once more. Regards. |
|||
| By: omuyelijah | Date: 30/05/2008 16:11:21 | Type : Assist |
|
| Hi VGR, some time later, when the web application was exposed to increasing number of clients, data integrity became a question, so I had 2 switch to the transactional approach and everything is fine. Thanks again. Sorry, I have not had time to call you but will soon. Bon Apres Midi. (Hope I got it right, cos its 3:00 pm afternoon here). Regards. |
|||
|
Do register to be able to answer |
|||
| Add This Article To: | |||
| |
|
|
|
| |
|
|
|









