Duplicate Entry Exceptions using sfPDOSessionStorage

this is a bug tracker not a q&a system

Could you please try my fix, which works for me? http://www.symfony-project.org/forum/index.php/m/65107/#msg_num_12

Michael

Replying to wissl:

As written in the forum topic below, there seems to be a problem using PDO as SessionStorage? right now. I am not able to locate the exact source of the problem, but using filestorage the issue does not raise. Who of the core team could check it please, ss this is the only option to use for database storage using propel 1.3... http://www.symfony-project.org/forum/index.php/t/15766/

Regarding this issue: could you devs check this? Sadly, it seems that not much people use pdo db sessions, as we are the only two with this issue. When i work on my project, close the browser and come back again (hours) later, i experience PDOException's, as wissl reported.

What i found out is that http://trac.symfony-project.org/browser/branches/1.2/lib/storage/sfPDOSessionStorage.class.php#L113 does not always return the data column (or false?), so an insert is executed, which of course fails, because the session already exists.

I changed this line to fetch the hole row instead of the first column ($stmt->fetchColumn()). Since then, no more PDOExceptions. This fix is confirmed by wissl: http://www.symfony-project.org/forum/index.php?t=rview&goto=65176#msg_65176

Here the fix for sfPDOSessionStorage.class.php:

113 if ($data = $stmt->fetchColumn()) 
114 { 
115   return $data; 
116 }

Change to:

113 if ($data = $stmt->fetch(PDO::FETCH_ASSOC)) 
114 { 
115   return $data[$db_data_col]; 
116 }

Michael

Hi Michael, I am considering changing this, however I would like to see if the num fetch mode works. If it does its a problem with fetchColumn, if not it seems to bee some indexing problem. I would prefer fetching by column number to avoid any problems with strange column names :-)

can you confirm this works?

113 if ($data = $stmt->fetch(PDO::FETCH_NUM)) 
114 { 
115   return $data[0]; 
116 }

Hi Fabian,

i reverted everything to it's original state and now i'm waiting since your post for the PDO exception so i can try the PDO::FETCH_NUM fix. I will report it asap.

Michael

(In [13142]) [1.2] attempt to close #4777. The bug might be caused either by the openDB cursor that at least pdo->fetch leaks, or misinterpreted return values (the if only would trigger if the assignment would evaluate to true). Now the number of rows returned is checked and the data is accessed using the 0,0 index, which should be much safer as well.

Dear Fabian,

today i experienced the exception which i've been waiting for. After applying your patch it works. I can now confirm your patch working for this rare bug.

Thank you for your work! Michael

Replying to FabianLange:

(In [13142]) [1.2] attempt to close #4777. The bug might be caused either by the openDB cursor that at least pdo->fetch leaks, or misinterpreted return values (the if only would trigger if the assignment would evaluate to true). Now the number of rows returned is checked and the data is accessed using the 0,0 index, which should be much safer as well.

Great! I had a bad feeling shooting at a bug which I could not reproduce. I hope this works now better, despite the fact that the real cause is still unknown