In my opinion it is a good behavior that EM closes and gives an exception,
it usually happens if SQL is invalid or some constraints. ORM cannot perform
any operations since it is a fatal issue.
The only thing which ORM could do is recognize the level of the failure in
transaction and decide weather it is a fatal exception or not.
You should use an extra wrapper in order to control it, this manager wrapper
could catch the exception, report an issue or failure, and create new
EntityManager with a same connection and configuration
Just an opinion.

On Mon, May 2, 2011 at 12:04 PM, Benjamin Eberlei <[email protected]>wrote:

> I will happily assist with ideas, i am just short on time at the moment.
> :-(
>
>
> On Mon, 02 May 2011 11:57:38 +0200, Fabien Potencier wrote:
>
>> On 3/26/11 10:43 AM, Lukas Kahwe Smith wrote:
>>
>>> Aloha,
>>>
>>> Not sure who is aware of this, but I learned this the hard way yesterday:
>>> If a transaction fails with Doctrine2, you might as well output a static
>>> page and die, because you cannot rely on anything that uses Doctrine2 ORM to
>>> still work and with all the possible listeners etc you are pretty much
>>> screwed.
>>>
>>> Doctrine2 EntityManager doesnt offer any method to get the EntityManager
>>> back into a working state, mainly because there are potentially references
>>> from proxies that would then point to a bogus EntityManager if the UoW would
>>> just be cleared. I do not know all the details, but Benjamin is pretty
>>> convinced its impossible to be able to fix an existing EntityManager
>>> instance.
>>>
>>> First up of course one should always try and prevent failed transactions.
>>> However its not always possible to do so without adding elaborate locking
>>> mechanisms to prevent any sort of race condition. Also in some cases it
>>> might just be too much overhead to try and verify everything (think
>>> importing a large XML file).
>>>
>>> So when a transaction does fail the only solution is to effectively make
>>> a totally new EntityManager according to Benjamin.
>>>
>>> Now if you use Container injecting this is less of a problem (though
>>> still  problem, more below). If you don't, you basically need to not only
>>> make the new instance, but you also need to magically find out all the
>>> places that follow the failed transaction (DB logger, rendered form with DB
>>> filled choice fields.
>>>
>>> Now if you do inject the Container everywhere and never assign it to a
>>> class property all you have to do is reset the service. However this is less
>>> trivial than you might think because of service aliasing:
>>>
>>> // reset the EM and all aias
>>> $container->set('doctrine.orm.entity_manager', null);
>>> $container->set('doctrine.orm.default_entity_manager', null);
>>> // get a fresh EM
>>> $em = $this->container->get('doctrine.orm.entity_manager');
>>>
>>> Now I am not sure if there is a method that would help me introspect the
>>> alias's, or if we need a magic method to be able to reset all aliases.
>>>
>>> Another approach could be of course to simply always clone the EM before
>>> starting any transaction, but that doesnt seem all too feasible.
>>>
>>> Another approach could be to simply always use a wrapper around the
>>> EntityManager that gets the Container injected and provides a reset()
>>> method.
>>>
>>> Thoughts, ideas, prayers? :)
>>>
>>
>> You have the same problem if you use transactions in your tests and
>> if you are explicitly testing failures.
>>
>> Anyway, I will work on this issue now as this is one of the biggest
>> possible pain point when using Doctrine2 with Symfony2.
>>
>> Fabien
>>
>>  regards,
>>> Lukas Kahwe Smith
>>> [email protected]
>>>
>>>
>>>
>>>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to