Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Clear set of readOnlyObjects in UnitOfWork #286

Closed
wants to merge 1 commit into from

3 participants

@saem

This fixes issues due to hash collisions, as spl_object_hash reuses hash values, when using clear interspersed within a bulk insert.

@stof

Please rebase your branch on top of master instead of 2.1.x:

$ git fetch upstream # being sure to have an uptodate remote
$ git rebase --onto upstream/master upstream/2.1.x patch-1
$ git push origin patch-1 --force
@saem

I followed your instructions, as you can see there isn't a huge pile of commits along with it.

@stof

did you change the line endings in the file to make so much changes ?

@saem

I used the github 'fork and edit' feature -- it might well have munged up the line endings.

@stof

Well, before the rebase, there was no such changes in the UnitOfWork replacing all lines. So it is not the "Edit and fork" feature

@saem

I don't follow, I'm pretty sure it is the "edit and fork" feature, as I do all my work in Linux, the only time I used Windows is at work, and even then my php environment is in a VM running Ubuntu, with PHPStorm (line-endings set to Unix, and encoding set to UTF-8). The github editor probably borked up the line-endings, so I know to be cautious of it.

Regardless, should we kill the pull request and create a new one with a saner patch?

@stof

yeah, probably

@beberlei
Owner

What did this commit do? clear readOnlyEntities when -<clear is called?

@saem

That's all it did, which fixed two bugs for us, one is a collision with hashes, the other is dangling references which consume memory in long running jobs.

Saem Ghani When persisting entities in a batch and employing partial references …
…(for performance), there can be hash collisions, manifesting as PDO errors regarding unbound parameters.

As stated in the spl_object_hash documentation (http://php.net/manual/en/function.spl-object-hash.php) it may reuse hash values. So, when inserting a large batch and clearing in between we get hash collisions which cause the EM/UoW to erroneously report some entities as read-only.

This should probably also be merged into master, as the bug also appears there.
fcafeef
@saem

I believe that should fix the diff.

@beberlei beberlei closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 20, 2012
  1. When persisting entities in a batch and employing partial references …

    Saem Ghani authored
    …(for performance), there can be hash collisions, manifesting as PDO errors regarding unbound parameters.
    
    As stated in the spl_object_hash documentation (http://php.net/manual/en/function.spl-object-hash.php) it may reuse hash values. So, when inserting a large batch and clearing in between we get hash collisions which cause the EM/UoW to erroneously report some entities as read-only.
    
    This should probably also be merged into master, as the bug also appears there.
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 0 deletions.
  1. +1 −0  lib/Doctrine/ORM/UnitOfWork.php
View
1  lib/Doctrine/ORM/UnitOfWork.php
@@ -2192,6 +2192,7 @@ public function clear($entityName = null)
$this->collectionDeletions =
$this->collectionUpdates =
$this->extraUpdates =
+ $this->readOnlyObjects =
$this->orphanRemovals = array();
if ($this->commitOrderCalculator !== null) {
Something went wrong with that request. Please try again.