2

I occationally recieve the following error resulting in failure of several pieces of code later in the pipeline.

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'QUyrgEInS_vO0GbrOhJffh6npb2ejlpllvS8Thn2pYY-Cu6Y9OkPd1qJuonzHQw2' for key 1: 
   UPDATE {sessions} 
   SET sid=:db_update_placeholder_0, ssid=:db_update_placeholder_1 
   WHERE (ssid = :db_condition_placeholder_0) ; 
Array ( 
   [:db_update_placeholder_0] => QUyrgEInS_vO0GbrOhJffh6npb2ejlpllvS8Thn2pYY 
   [:db_update_placeholder_1] => Cu6Y9OkPd1qJuonzHQw2JI67BDvO85pqp50SBsXE1ZU 
   [:db_condition_placeholder_0] => fMabX3y84Ngm-HcGF8MomLvLp1kmceLRIwniv_dSj_M ) 
in drupal_session_regenerate() (line 393 of /var/aegir/platforms/demandmetric/includes/session.inc).

I am using custom code that rougly looks like this:

drupal_session_start();
_$SESSION[''] = bunch of generated info.
Authorize linkedin
create user
$form_state['uid'] = $account->uid;
user_login_submit(array(), $form_state);
Update profile from linkedin info.

The error occurs on the user login submit part.

I suspect that drupal_session_start is causing the issue but I don't understand sessions well enough to debug this. The issue occurs 1 in about 30 users. I added the session start because the session info on line 2 doesn't get set without it.

Other suspects are memcache (very unlikely) and secure pages.

Anyone know about session that can enlighten me to how to track this issue down?

  • 1
    I think you should possibly be calling drupal_session_regenerate rather than drupal_start_session, as that seems a better match for your purpose, as far as I can tell. api.drupal.org/api/drupal/includes%21session.inc/function/… – Alfred Armstrong Oct 18 '13 at 15:48
  • Alfred, regenerate seems to work in place of start. I pushed that change to see if I will get another occurrence of the duplicate session thing. If someone explain to me how these functions are different better than the documentation on api.drupal.org it would be appreciated. – danielson317 Oct 18 '13 at 16:19
  • Can you elaborate what the user_login_submit(array(), $form_state); does? Are you doing this to fake a login? And, if so, is there a reason you need the session before you do this? – mpdonadio Oct 18 '13 at 20:38
  • user_login_submit(array(), $form_state) is not to fake a login. It actually performs a login. It's the way drupal core does a login through code so I just nabbed the snippet form there. The session is needed to validate the user when they come back from being authorized by linkedin. Not actually related to the login. – danielson317 Oct 18 '13 at 21:04
  • Too soon to say for sure but it appears regenerate in place of start is the right answer. Alfred if you post an answer I'll be able to give it to you. – danielson317 Oct 24 '13 at 15:18
1

Check your sites/default/settings.php file, if you have $conf[https] = TRUE; then removing it will fix the error.

Removing it also won't affect any security issues as long as your server/domain is configured properly. You can also check the Enabling HTTP Secure page from Drupal.

0

Just leave out drupal_session_start();. You simple can assigning stuff to $_SESSION (even for anonymous users). The data will be still present after a login. For an example of how this works, I'd suggest examining the shopping cart module of Drupal Commerce.

Note that this does not work when logging out for obvious reasons (session is destroyed on logout).

  • Unfortunately this is not true in practice. I added the session start because the session was not getting set up correctly. I defined several session variables and they were all blank when accessing them later in the same function. The session start fixed that. I'll peak at drupal commerce and see how they do it though. that's a good idea. – danielson317 Oct 24 '13 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.