Development

#4777 (Duplicate Entry Exceptions using sfPDOSessionStorage)

You must first sign up to be able to contribute.

Ticket #4777 (closed defect: fixed)

Opened 8 months ago

Last modified 8 months ago

Duplicate Entry Exceptions using sfPDOSessionStorage

Reported by: wissl Assigned to: michael.piecko
Priority: major Milestone: 1.2.0 RC1
Component: other Version:
Keywords: Cc:
Qualification: Unreviewed

Description

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/

Change History

10/30/08 13:16:13 changed by wissl

  • version set to 1.1.4.

10/30/08 13:20:58 changed by FabianLange

  • status changed from new to closed.
  • resolution set to invalid.

this is a bug tracker not a q&a system

(in reply to: ↑ description ; follow-up: ↓ 4 ) 11/13/08 10:49:25 changed by michael.piecko

  • status changed from closed to reopened.
  • version deleted.
  • resolution deleted.

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/

(in reply to: ↑ 3 ) 11/14/08 10:48:25 changed by michael.piecko

  • milestone set to 1.2.0 RC1.

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

(follow-up: ↓ 6 ) 11/14/08 21:48:00 changed by FabianLange

  • owner changed from fabien to michael.piecko.
  • status changed from reopened to new.

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 }

(in reply to: ↑ 5 ) 11/17/08 09:23:33 changed by michael.piecko

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

(follow-up: ↓ 8 ) 11/18/08 23:21:02 changed by FabianLange

  • status changed from new to closed.
  • resolution set to fixed.

(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.

(in reply to: ↑ 7 ) 11/20/08 14:00:06 changed by michael.piecko

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.

11/20/08 16:21:39 changed by FabianLange

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

The Sensio Labs Network

Since 1998, Sensio Labs has been promoting the Open-Source software movement by providing quality web application development, training, consulting, and supporting several large Open-Source projects.