[seam-dev] [seam-persistence] ManagedPersistenceContextExtension
Jason Porter
lightguard.jp at gmail.com
Mon Jul 11 11:00:49 EDT 2011
This sounds like excellent material to add to the Seam Persistence docs! Mark, would mind either adding it or pasting it into a JIRA so it doesn't get lost?
Sent from my iPhone
On Jul 11, 2011, at 1:53, Mark Struberg <struberg at yahoo.de> wrote:
> Hi Emmanuel!
>
> My point is: Some features of seam-persistence are more a seam-hibernate (as upgrade path from Seam2 this makes perfect sense I guess) than a general JPA thingy. They only work with Hibernate and cannot be generalized to other JPA providers! And even if you use Hibernate, then there are a few restrictions which should get added to the documentation. I'll try to sum up:
>
> If you use a scope bigger than @RequestScoped on the EnitityManagerProducer then:
>
> * This only works with Hibernate and FlushMode.MANUAL. No other JPA provider will do since the EntityManager impls are usually _not_ Serializable.
>
> * The problem is that most queries will be performed inside a @Transactional bracelet thus they might have an open transaction. In this case there is no temp-transaction which could be rollbacked. Thus the 'baby non auto-flush' doesn't work out I fear.
>
> * Also in JPA managed entities must not get accessed from multiple threads in parallel. All scopes longer than @RequestScoped are subject of being hit by parallel AJAX calls or requests from multiple windows. It's only a matter of load to get this situation. I was easily able to reproduce such scenarios with JMeter [1] with 50 parallel threads.
>
> * EntityManager#lock must not get used.
>
> * native Queries might return wrong results.
>
> * non-trivial Queries might return wrong results.
>
> * no select for update allowed.
>
>
> But I agree completely with you that a Serializable EntityManager would be a BIG benefit. I frankly fear this is only possible by dropping all the pessimistic locking stuff and not doing so much things automatically. There is a JPA-like project called eBean [2] which does exactly that. But it's not a JPA provider exactly because of that...
>
> Imo the easiest way to cope with that situation is to emulate the transactional stuff of EJB with an extended EntityManager. Opening the transaction once the outer @Transactional gets entered, and committing/rollback + closing the EntityManager as soon as you leave the outermost @Transactional method. This will detach all entities immediately, so they can be transfered, used, whatever... One just needs to em.merge them to get them stored later.
>
> I'm not sure about Hibernate, but OpenJPA and Eclipselink both store _loaded and _dirty bitfields in detached entities and this info will also get serialized along the line.
>
> LieGrue,
> strub
>
> [1] http://jakarta.apache.org/jmeter/
> [2] http://www.avaje.org/
>
> --- On Mon, 7/11/11, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> From: Emmanuel Bernard <emmanuel at hibernate.org>
>> Subject: Re: [seam-dev] [seam-persistence] ManagedPersistenceContextExtension
>> To: "Mark Struberg" <struberg at yahoo.de>
>> Cc: "John D. Ament" <john.d.ament at gmail.com>, "seam-dev at lists.jboss.org" <seam-dev at lists.jboss.org>
>> Date: Monday, July 11, 2011, 12:08 AM
>> Hibernate has the notion of
>> FlushMode.MANUAL to prevent operations from being pushed to
>> the DB even upon queries. JPA has a baby version of that
>> with extended persistence contexts behaving outside
>> transactions.
>>
>> Yes some methods like lock are not allowed when the em is
>> expected to be passivated. But that's not a reason to
>> disable a useful feature (passivation) altogether.
>> Passivation is sometimes not possible but that far from
>> your statement "This is never _never_ NEVER true. The
>> EntityManager is not Serializable!".
>>
>> Emmanuel
>>
>> PS: There are more efficient ways to passivate an
>> entityManager than serializing it with some help from the
>> persistence provider. I don't remember if we ever finished
>> this work.
>>>
>>
>>
>> On 11 juil. 2011, at 01:44, Mark Struberg <struberg at yahoo.de>
>> wrote:
>>
>>> There are a few problems which can happen:
>>>
>>> a.) EmtityManager#lock(java.lang.Object o,
>> javax.persistence.LockModeType lockModeType); and others
>> with LockType#PESSIMISTIC_*
>>>
>>> b.) Consider you have an Entity dirty or a fresh one
>> created with em.persist(). And now you do a non-trivial
>> query. In order to guarantee that this new/modified entity
>> gets evaluated properly, JPA _explicitly_ allows the
>> EntityManager to write those values into the database.
>> Voila, you have your open transaction! Not too many people
>> are aware of that but yes, querying from the database can
>> lead to a SQL INSERT or SQL UPDATE into the database! Of
>> course, you better _not_ commit those changes immediately
>> ;)
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> --- On Sun, 7/10/11, John D. Ament <john.d.ament at gmail.com>
>> wrote:
>>>
>>> From: John D. Ament <john.d.ament at gmail.com>
>>> Subject: Re: [seam-dev] [seam-persistence]
>> ManagedPersistenceContextExtension
>>> To: "Mark Struberg" <struberg at yahoo.de>
>>> Cc: "Stuart Douglas" <stuart.w.douglas at gmail.com>,
>> seam-dev at lists.jboss.org
>>> Date: Sunday, July 10, 2011, 11:29 PM
>>>
>>> But is the select for update done inside the
>> entitymanager object or a query instance? I don't
>> think EntityManager.find(Class,Id) does any type of hold on
>> the object found.
>>>
>>> John
>>>
>>>
>>> On Sun, Jul 10, 2011 at 7:15 PM, Mark Struberg <struberg at yahoo.de>
>> wrote:
>>>
>>> Stu, whenever you do a "select for update" or any
>> manual locking, you will end up with an EntityManager which
>> cannot be transfered to another node. Even if hibernate
>> marks it's EntityManager Serializable, it just isn't if I
>> didn't miss something!
>>>
>>>
>>>
>>>
>>> LieGrue,
>>>
>>> strub
>>>
>>>
>>>
>>> --- On Sun, 7/10/11, Stuart Douglas <stuart.w.douglas at gmail.com>
>> wrote:
>>>
>>>
>>>
>>>> From: Stuart Douglas <stuart.w.douglas at gmail.com>
>>>
>>>> Subject: Re: [seam-dev] [seam-persistence]
>> ManagedPersistenceContextExtension
>>>
>>>> To: "Mark Struberg" <struberg at yahoo.de>
>>>
>>>> Cc: seam-dev at lists.jboss.org
>>>
>>>> Date: Sunday, July 10, 2011, 11:07 PM
>>>
>>>>
>>>
>>>> On 11/07/2011, at 4:07 AM, Mark Struberg wrote:
>>>
>>>>
>>>
>>>>> Hi folks!
>>>
>>>>>
>>>
>>>>> While reviewing an OWB bug report, 2 questions
>> came
>>>
>>>> up:
>>>
>>>>>
>>>
>>>>> a.) EnvironmentUtils#isEEEnvironment() relies
>> on the
>>>
>>>> absence of 'javax.ejb.Stateless' to decide if a
>>>
>>>> PersitenceUnit gets injected or if you need to do
>> it
>>>
>>>> yourself. I think this is an unrelieable
>> assumption. E.g.
>>>
>>>> there are a few Extensions which emulate Stateless
>> Session
>>>
>>>> beans via a CDI Extension by morphing them into
>>>
>>>> @ApplicationScoped.
>>>
>>>>
>>>
>>>> This is not ideal, but I don't think there is
>> really any
>>>
>>>> portable way to detect if the environment is an
>> EE
>>>
>>>> environment or not. I was originally planning to
>> add a
>>>
>>>> method for configuring this, but it appears I did
>> not get
>>>
>>>> around to it.
>>>
>>>>
>>>
>>>>>
>>>
>>>>> b.) in
>>>
>>>>
>> ManagedPersistenceContextExtension#registerManagedPersistenceContext
>>>
>>>> you register the bean for the EntityManager as
>>>
>>>> passivationCapable. This is never _never_ NEVER
>> true. The
>>>
>>>> EntityManager is not Serializable! There is imo no
>> way to
>>>
>>>> have an EntityManager in a bean scoped other than
>>>
>>>> @RequestScoped or shorter (e.g.
>> @TransactionalScoped). Any
>>>
>>>> other trick is not working in a portable way. This
>> is mainly
>>>
>>>> caused by JPA still supporting pessimistic locking
>> (_real_
>>>
>>>> locks in the database) as first class citizens.
>>>
>>>>>
>>>
>>>>
>>>
>>>> Without this it is not possible to have a
>> conversation
>>>
>>>> scoped entity manager. The hibernate EntityManager
>> is in
>>>
>>>> fact Serializable. Locks should not be a problem
>> as long as
>>>
>>>> you do not attempt to serialise the EM in the
>> middle of a
>>>
>>>> transaction.
>>>
>>>>
>>>
>>>> Stuart
>>>
>>>>
>>>
>>>>
>>>
>>>>> But I'd be happy if anyone could enlighten me
>> and tell
>>>
>>>> us how it works ;)
>>>
>>>>>
>>>
>>>>> LieGrue,
>>>
>>>>> strub
>>>
>>>>>
>> _______________________________________________
>>>
>>>>> seam-dev mailing list
>>>
>>>>> seam-dev at lists.jboss.org
>>>
>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>>
>>>
>>>>
>>>
>>> _______________________________________________
>>>
>>> seam-dev mailing list
>>>
>>> seam-dev at lists.jboss.org
>>>
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
More information about the seam-dev
mailing list