Skip to content

[Messenger] Automatically clear the entity manager at each message consumption #29662

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ghost opened this issue Dec 21, 2018 · 5 comments
Closed

Comments

@ghost
Copy link

ghost commented Dec 21, 2018

Description

@sroze Hi, do you think there is any good way to automatize the doctrine entity manager clear between message consumption? Do you think it could be a good idea to provide an embedded middleware to do this on Received stamped messages for example?

The use case is: when the worker is running (and not stopped between each messages), if an entity is fetched from the database, it may not be refresh between two messages handling. For example, in the case of an user account recovery process (email sent async with messenger and amqp), if the email address is updated after the first try, the second email is send to the old email address.

@ogizanagi
Copy link
Contributor

Makes sense to me 😉

@sroze
Copy link
Contributor

sroze commented Mar 20, 2019

Makes sense to me as well to ship such a middleware within the DoctrineBridge (& configured in DoctrineBundle) 👍

@OK1BR
Copy link

OK1BR commented Mar 29, 2019

$this->entityManager->clear(); ?

@zmitic
Copy link

zmitic commented Apr 3, 2019

Shouldn't that happen with all resettable services?

@ogizanagi
Copy link
Contributor

Resettable services are only reset on next kernel boot() call. Also, only for requests (\Symfony\Component\HttpKernel\Kernel::handle). So it won't happen in CLI. This feature request is about clearing the manager while the worker command is executing.
Clearing it between each handling inside a middleware will provide state isolation and save memory.

Koc added a commit to Koc/symfony that referenced this issue Apr 30, 2019
Koc added a commit to Koc/symfony that referenced this issue May 7, 2019
Koc added a commit to Koc/symfony that referenced this issue May 10, 2019
Koc added a commit to Koc/symfony that referenced this issue May 12, 2019
Koc added a commit to Koc/symfony that referenced this issue May 27, 2019
Koc added a commit to Koc/symfony that referenced this issue May 29, 2019
Koc added a commit to Koc/symfony that referenced this issue Jun 3, 2019
@fabpot fabpot closed this as completed Jun 4, 2019
fabpot added a commit that referenced this issue Jun 4, 2019
This PR was merged into the 4.4 branch.

Discussion
----------

[Messenger] Add clear Entity Manager middleware

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #29662
| License       | MIT
| Doc PR        | TBD

General purpose of this middleware:
* avoid memory leaks during messages handling
* prevent unexpected side effects when entities that already stored in identity map not refreshed between messages

Commits
-------

6e690a6 Add clear Entity Manager middleware (closes #29662)
fabpot added a commit that referenced this issue Jun 4, 2019
* 4.4:
  Extract Abstract Doctrine Middleware
  [Translation] refactor ArrayLoader::flatten
  [TwigBundle] mark TemplateIterator as internal
  Improved error message on create a form builder with invalid options
  [Security] add PasswordEncoderInterface::needsRehash()
  [HttpClient] add $response->cancel()
  Add clear Entity Manager middleware (closes #29662)
  [FrameworkBundle] Add missing BC layer for deprecated ControllerNameParser injections
  [Validator] Improve TypeValidator to handle array of types
  Add exception as HTML comment to beginning and end of `exception_full.html.twig`
  [Validator] Add compared value path to violation parameters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants