On 20.06.2011, at 11:50, Emmanuel Bernard wrote:
> As you said, this is not a great solution as it does not cover non-managed entities.
>
> Just to clarify, let me try and summarize why I think the EG has not introduced such feature so far.
>
> I'd say the #1 reason is that we believe in domain models that are not tied to a particular persistence / serialization technology. Entities are meant to be potentially serialized and passed around to other layers of the application. Managing the injection of an EM in this case will be awkward at best.
Rich Domain Entities are typically not going to be serialized. They are usually directly bound to a UI technology in process. Detaching rich domain entities cause synchronization challenges.
> The #2 reason is more defensive. If a user ends up calling an EM method within a getter / setter or lifecycle method, pretty much all bets are off. Best case, the EM goes into some undefined state, worst case you get at StackOverflowException. This is of course very dependent of the underlying implementation but I remember thinking about this problem hack in the JPA 1 days and concluding that allowing such thing to work in *some* situations would make the specification much more complex as well as reduce the capabilities of a provider implementation for optimization or enforce (CPU) costly checks in many areas.
In most of the non-trivial projects I seen the EntityManager was passed to the Entities in many strange ways. Everything you wrote above can also happens in this case.
>
> We can try and revisit that but it seems to me that you're trying to apply the ActiveRecord pattern to JPA entities. I think that while this pattern can be quite useful in languages with proper mixins and in particular dynamic languages, it would be much more awkward in Java. If you think about it, EJB Entity 1 / 2 was trying to achieve that but it does not raise fond memories :) Also, JPA does not forces you to have anemic domain models, it just asks you to keep your *persistence* related methods out of the domain model.
Attachment / detachment listener could be used in variety of things. I would use it for the implementation of rich domain objects. IMHO: we should not try to protect the developers.
adam
>
> Emmanuel
>
> On 18 juin 2011, at 12:53, Adam Bien wrote:
>
>> Hi All,
>>
>> I would like to introduce a LifecycleListener and Lifecycle Call Back methods like:
>>
>>
>> @PostAttach
>> public void postAttach(EntityManager manager){
>>
>> }
>>
>> @PreDetach
>> public void preDetach(){}
>>
>> Reason:
>>
>> In rich domain entities it is often required to get a reference to an EntityManager to be able to create and persist new entities or to perform queries.
>>
>> Currently it is only possible with workarounds like using ThreadLocal or ThreadSynchronizationRegistry. With an extension of the lifecycle listener you would get
>> a reference to an EntityManager and will get notified in case it is no more valid.
>>
>> Injection of the EntityManager would be the best/easiest solution, however JPA-entities are managed by the EntityManager and not by the container...
>>
>> I have the issue in every non-trivial project with a rich domain object model. There are, however, no issues with an anemic (http://www.martinfowler.com/bliki/AnemicDomainModel.html) model, because usually the EJBs / CDI managed beans do implement the business logic.
>>
>> see also: http://www.adam-bien.com/roller/abien/entry/why_sometimes_the_entitymanager_in
>>
>> best regards,
>>
>> adam
>>
>