We have several deployments under on uniserver running.
So we have a acceptation and a real environment. Now when we deploy an app in acceptation and I set the database connection and test it it all works. Then when I deploy it in the real environment and I make the database connection then the connection is made properly. But when I want to use it, it shows the connection from the acceptation environment, even tho the settings are correct. Of course
both environments have their OWN session id’s named ACCSESSID and PRDSESSID so they should not be confusing each other.
Apparently the database connection and path to the main application is stored in prod.config.php, so for both environments they do differ.
Very oddly enough they both make use of the same database. Can someone explain how this works in detail (please SC??).
I thought that if I deploy one and set the database connection and deploy another and set that database connection that they both use their own database connections. Apparently there is another check somewhere that screws this mechanism up a bit.
Are you sure that you have not accidentally selected “Store Session Data in Database”?
I saw some problems that I believe are related to yours when setting up our deploy environment, we have a similar configuration, a test site and a production site, both are running from the same instance of apache as separate virtual hosts, and both are accessing the same MySQL database. The solution for me was to name the two sites differently, rather than having differently named cookies, which seemed to solve all the issues.
Originally we had something like www.zotto.com/test and www.zotto.com as the two sites, with different named cookies. It seemed like we got sporadic bad (wrong) session data. I never bothered to track down exactly what caused it. We renamed the sites to www.zotto.com and test.zotto.com, both using the same cookie name, “PHPSESSID”. Suddenly life was wonderful, no more errors.
On another project, we use “Session Data in Database” because we have a load balancer on the front end of multiple identical web servers. This seems to work well as far as I can tell.
Hope some of this might help.
Dave
Nope we havent. We did a more thorough check and saw that in prod_config.php that when the database is different that the middle part of the encoded string should be different.
Even tho I kill the cookie it doesnt seem to help. Apparently it can get screwed up. I guess where stuck to a full redeployment in such a case…
How are you setting the different cookie names, in .htaccess ?
The different cookies are set via the .htaccess file in the root of the environments. So in my …/acc dir there is this
php_value session.name “ACCSESSID”
php_value session.gc_maxlifetime 14400
in my …/PRD there is this
php_value session.name “PRDSESSID”
php_value session.gc_maxlifetime 14400
That works actually quite well. This way these environments are not disturbing each other and I can run multiple environments using the same browser at the same time.
[QUOTE=rr;34444]The different cookies are set via the .htaccess file in the root of the environments. So in my …/acc dir there is this
php_value session.name “ACCSESSID”
php_value session.gc_maxlifetime 14400
in my …/PRD there is this
php_value session.name “PRDSESSID”
php_value session.gc_maxlifetime 14400
That works actually quite well. This way these environments are not disturbing each other and I can run multiple environments using the same browser at the same time.[/QUOTE]
That should be fine. Have you tested different domain names just to see if the symptoms disappear?
Dave
We did a complete redeployment… Apparently that worked, I guess something stayed in memory somewhere. Using a different domain shoul resolve it indeed. Anyway I know a way around it tho it is cumbersome…
Now you mentioned. I had a strange behaviour about unresponse and solved upgrading Uniform (version deployed was from 2 months). Still a mistery for me what really happened.
Good point I can update that one too.