If you have multiple calls to the database that are grouped, definitely perform them during the same connection session. The bottom line is unless the overhead associated with opening and closing the connection is going to be an issue programmatically, keep connections brief and group your transactions where possible. A good example would be you have a group of calls (A, B, C) that need to happen. Calls A and B can run one after the other, but C has to wait on a user input (no matter how small/simple), you should open the connection, run calls A and B, close the connection waiting on user input, then reopen, run call C, then close the connection. A good exception to this rule would be if you have calls that have to run every 'x' milliseconds and you anticipate that you MIGHT at ANY point run into concurrency issues, you would hold a single open connection for that specific case and adhere to the 'open'-'run calls'-'close' standard for all other cases. Remember, we rarely know what new tasks our programs will be doing in the future so building for scalability is always a good bet.
Respectfully, Joshua D. Arneson Data Manager, Mount Sinai NIH Brain & Tissue Repository (NBTR) 130 W Kingsbridge Rd, Rm 5F-04 Bronx, NY 10468 Email: joshua.arne...@mssm.edu Office: 718-584-9000 ext 6094 Mobile: 347-915-8911 Fax: 718-741-4746 > On Mar 5, 2017, at 7:29 PM, Karl DeSaulniers <k...@designdrumm.com> wrote: > > Ah, thanks for the reply Joshua. > > Duly noted. So when is it bad to make multiple open and close connections > then? > I am guessing that could have some impact with lots of users too. Yes? > > If the website in question does not have a lot of users (less than 1,000), is > this still a bad call to keep an open connection? > If so, should I be closing the connection after each page load that has > multiple calls on the database? > Or after each call to the database? > > I am wanting to make sure I am not doing something bad or dangerous when > holding these sessions open. > If it is a matter of taste, I'll leave it, but if it is a matter of best > practices to open and close, I will change the method I am using. > > Again, TIA! > > Best, > > Karl DeSaulniers > Design Drumm > https://urldefense.proofpoint.com/v2/url?u=http-3A__designdrumm.com&d=DwIFAg&c=shNJtf5dKgNcPZ6Yh64b-A&r=HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=w7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6fBstsA&s=JzvStr8fa_OyNaHOUe0Xp8_o6aDzZSgZ6OXyEk6WyIM&e= > > > > >> On Mar 5, 2017, at 6:19 PM, Arneson, Joshua <joshua.arne...@mssm.edu> wrote: >> >> Right off the bat, you need to consider concurrency issues. Depending on the >> size of your user base and level of activity this could become a major >> issue. In the end, why hold an open connection for 15 minutes just to >> process 20-30 transactions that take 20-30ms each? Just better (under most >> circumstances) to open the connection, process your transaction , then close >> the connection. >> >> Respectfully, >> >> Joshua D. Arneson >> Data Manager, Mount Sinai NIH Brain & Tissue Repository (NBTR) >> 130 W Kingsbridge Rd, Rm 5F-04 >> Bronx, NY 10468 >> Email: joshua.arne...@mssm.edu >> Office: 718-584-9000 ext 6094 >> Mobile: 347-915-8911 >> Fax: 718-741-4746 >> >>> On Mar 5, 2017, at 6:54 PM, Karl DeSaulniers <k...@designdrumm.com> wrote: >>> >>> Hello everyone, >>> Long time. Hope all are well. >>> >>> Quick question. How should MySQL connections be treated? >>> Is it ok to leave them open or is it better to close them after >>> transactions? >>> I have a website that uses sessions and was wondering if there was any >>> situations where I should be closing the connection. >>> Either for performance reasons or security or best practices. >>> >>> Just wondering your professional. >>> >>> TIA >>> >>> Best, >>> >>> Karl DeSaulniers >>> Design Drumm >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__designdrumm.com&d=DwIFAg&c=shNJtf5dKgNcPZ6Yh64b-A&r=HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=09oI7Bn2rpePGXSl8CmHMTUqhm3Rjh676OnMYed0L_4&s=JBoK9bslzQegAxQDG_NbsuvcCBLw5_LIQkjMpEj4kE8&e= >>> >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__designdrumm.com_&d=DwIFAg&c=shNJtf5dKgNcPZ6Yh64b-A&r=HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=09oI7Bn2rpePGXSl8CmHMTUqhm3Rjh676OnMYed0L_4&s=u_sgRk_DWdl5PZZinSHklw5DuV7oz5cv7MWZCJDsJzA&e=> >>> >>> >>> >>> >> >> -- >> PHP Database Mailing List >> (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_&d=DwIFAg&c=shNJtf5dKgNcPZ6Yh64b-A&r=HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=w7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6fBstsA&s=wWlQEGEfTaOWZtdTA776DTMosB5WtSX6K5iaiWM7J3A&e= >> ) >> To unsubscribe, visit: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_unsub.php&d=DwIFAg&c=shNJtf5dKgNcPZ6Yh64b-A&r=HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=w7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6fBstsA&s=qSyyKaFDMntOGvbZ-jgs6sfh-DyfkxT3tTOLa-uFDDw&e= >> > > > -- > PHP Database Mailing List > (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_&d=DwIFAg&c=shNJtf5dKgNcPZ6Yh64b-A&r=HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=w7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6fBstsA&s=wWlQEGEfTaOWZtdTA776DTMosB5WtSX6K5iaiWM7J3A&e= > ) > To unsubscribe, visit: > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_unsub.php&d=DwIFAg&c=shNJtf5dKgNcPZ6Yh64b-A&r=HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=w7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6fBstsA&s=qSyyKaFDMntOGvbZ-jgs6sfh-DyfkxT3tTOLa-uFDDw&e= > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
