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 <[email protected]> wrote: From: John D. Ament <[email protected]> Subject: Re: [seam-dev] [seam-persistence] ManagedPersistenceContextExtension To: "Mark Struberg" <[email protected]> Cc: "Stuart Douglas" <[email protected]>, [email protected] 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 <[email protected]> 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 <[email protected]> wrote: > From: Stuart Douglas <[email protected]> > Subject: Re: [seam-dev] [seam-persistence] ManagedPersistenceContextExtension > To: "Mark Struberg" <[email protected]> > Cc: [email protected] > 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 > > [email protected] > > https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
