Re: MySQL connection

If you have multiple calls to the database that are grouped, definitely per=
form 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 transacti=
ons 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 t=
he connection, run calls A and B, close the connection waiting on user inpu=
t, 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' millisecond=
s and you anticipate that you MIGHT at ANY point run into concurrency issue=
s, you would hold a single open connection for that specific case and adher=
e 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.=20

Respectfully,

Joshua D. Arneson
Data Manager, Mount Sinai NIH Brain & Tissue Repository (NBTR)
130 W Kingsbridge Rd, Rm 5F-04
Bronx, NY 10468
Email: [email protected]
Office: 718-584-9000 ext 6094
Mobile: 347-915-8911
Fax: 718-741-4746

> On Mar 5, 2017, at 7:29 PM, Karl DeSaulniers <[email protected]> wrote=
:
>=20
> Ah, thanks for the reply Joshua.
>=20
> 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?
>=20
> 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 m=
ultiple calls on the database?
> Or after each call to the database?=20
>=20
> 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.
>=20
> Again, TIA!
>=20
> Best,
>=20
> Karl DeSaulniers
> Design Drumm
> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__designdrumm.com&d=
=3DDwIFAg&c=3DshNJtf5dKgNcPZ6Yh64b-A&r=3DHSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBk=
Q0VGj7tYk&m=3Dw7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6fBstsA&s=3DJzvStr8fa_OyN=
aHOUe0Xp8_o6aDzZSgZ6OXyEk6WyIM&e=3D
>=20
>=20
>=20
>=20
>> On Mar 5, 2017, at 6:19 PM, Arneson, Joshua <[email protected]> wr=
ote:
>>=20
>> 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 proc=
ess 20-30 transactions that take 20-30ms each? Just better (under most circ=
umstances) to open the connection, process your transaction , then close th=
e connection.=20
>>=20
>> Respectfully,
>>=20
>> Joshua D. Arneson
>> Data Manager, Mount Sinai NIH Brain & Tissue Repository (NBTR)
>> 130 W Kingsbridge Rd, Rm 5F-04
>> Bronx, NY 10468
>> Email: [email protected]
>> Office: 718-584-9000 ext 6094
>> Mobile: 347-915-8911
>> Fax: 718-741-4746
>>=20
>>> On Mar 5, 2017, at 6:54 PM, Karl DeSaulniers <[email protected]> wro=
te:
>>>=20
>>> Hello everyone,
>>> Long time. Hope all are well.
>>>=20
>>> Quick question. How should MySQL connections be treated?
>>> Is it ok to leave them open or is it better to close them after transac=
tions?
>>> 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.=20
>>>=20
>>> Just wondering your professional.
>>>=20
>>> TIA
>>>=20
>>> Best,
>>>=20
>>> Karl DeSaulniers
>>> Design Drumm
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__designdrumm.com&d=
=3DDwIFAg&c=3DshNJtf5dKgNcPZ6Yh64b-A&r=3DHSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBk=
Q0VGj7tYk&m=3D09oI7Bn2rpePGXSl8CmHMTUqhm3Rjh676OnMYed0L_4&s=3DJBoK9bslzQegA=
xQDG_NbsuvcCBLw5_LIQkjMpEj4kE8&e=3D <https://urldefense.proofpoint.com/v2/u=
rl?u=3Dhttp-3A__designdrumm.com_&d=3DDwIFAg&c=3DshNJtf5dKgNcPZ6Yh64b-A&r=3D=
HSbgyt8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=3D09oI7Bn2rpePGXSl8CmHMTUqhm3=
Rjh676OnMYed0L_4&s=3Du_sgRk_DWdl5PZZinSHklw5DuV7oz5cv7MWZCJDsJzA&e=3D>
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>> --
>> PHP Database Mailing List (https://urldefense.proofpoint.com/v2/url?u=3D=
http-3A__www.php.net_&d=3DDwIFAg&c=3DshNJtf5dKgNcPZ6Yh64b-A&r=3DHSbgyt8GFSy=
WQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=3Dw7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6f=
BstsA&s=3DwWlQEGEfTaOWZtdTA776DTMosB5WtSX6K5iaiWM7J3A&e=3D )
>> To unsubscribe, visit: https://urldefense.proofpoint.com/v2/url?u=3Dhttp=
-3A__www.php.net_unsub.php&d=3DDwIFAg&c=3DshNJtf5dKgNcPZ6Yh64b-A&r=3DHSbgyt=
8GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=3Dw7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3n=
ukN6fBstsA&s=3DqSyyKaFDMntOGvbZ-jgs6sfh-DyfkxT3tTOLa-uFDDw&e=3D=20
>=20
>=20
> --
> PHP Database Mailing List (https://urldefense.proofpoint.com/v2/url?u=3Dh=
ttp-3A__www.php.net_&d=3DDwIFAg&c=3DshNJtf5dKgNcPZ6Yh64b-A&r=3DHSbgyt8GFSyW=
Q53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=3Dw7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nukN6fB=
stsA&s=3DwWlQEGEfTaOWZtdTA776DTMosB5WtSX6K5iaiWM7J3A&e=3D )
> To unsubscribe, visit: https://urldefense.proofpoint.com/v2/url?u=3Dhttp-=
3A__www.php.net_unsub.php&d=3DDwIFAg&c=3DshNJtf5dKgNcPZ6Yh64b-A&r=3DHSbgyt8=
GFSyWQ53Nxworjip-dgIKnMlPBkQ0VGj7tYk&m=3Dw7VxdOhlxCY27A_sfaFCxntsWMG8ZDA3nu=
kN6fBstsA&s=3DqSyyKaFDMntOGvbZ-jgs6sfh-DyfkxT3tTOLa-uFDDw&e=3D=20
>=20

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php