[FLOW3-general] Possible Memory Problem within Flow3

[Karsten Dambekalns]

Hi Chris.

On 29.11.11 13:20, Chris Zepernick wrote:
> This call creates, at least this is what i got as error message the time
> I turned that line into a comment, the persistence identifier and adds
> the object to \TYPO3\FLOW3\Core\Bootstrap::$staticObjectManager.
> 
> My question is why is this done on __construct of an entity?
> 
> As far as I get it the identifier is only needed at persist of an object.

No, the identifier is needed when you create a link that somehow needs
to address your new object, e.g..

> Second Question is why is each instance of an entity stored into
> \TYPO3\FLOW3\Core\Bootstrap::$staticObjectManager ?

You mean the call to registerNewObject() that is done? That is so you
can actually find objects not yet persisted in a consistent way.

Believe me, both things are really needed, we learned that over time.

> This would be a second storage for the same object besides the entities
> repository, and at the moment I can find no way to unset an object that
> was created by new Bla(); Wich increases memory usage at bulk jobs to a
> level where one runs into a memory leak.

That is true. For real bulk inserts, your best bet (also with plain
Doctrine 2) is to insert into the DB directly. Nothing beats that.

When going through the ORM layer one needs to do some cleanup. I
remember a thread earlier this year where (I think) Regine did some
experiments and solved the issue for her. I could not find that thread
anympre, though. It would be nice to check her approach and see if that
(still) works well (enough).

> Last Question is more general, we discovered that the detach() method
> from Doctrine has not yet been implemented into the standard repository
> for entities, to my mind this would make a lot of sense in case one
> would like to CUD (Create, Update, Delete) a lot of entities at once.

Well, the API of the Repository class serves both generic and Doctrine
persistence, so  we kept it simple. There is the Doctrine-specific
Repository class which also gives you easy access to DQL and events, so
we could look into making it available there.

Do you think you could write a functional test for a massive import
scenario?

Regards,
Karsten