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(a)gmail.com> wrote:
From: John D. Ament <john.d.ament(a)gmail.com
Subject:
Re: [seam-dev] [seam-persistence] ManagedPersistenceContextExtension
To: "Mark Struberg" <struberg(a)yahoo.de
Cc:
"Stuart Douglas" <stuart.w.douglas(a)gmail.com>, seam-dev(a)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(a)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(a)gmail.com> wrote:
From: Stuart Douglas <stuart.w.douglas(a)gmail.com>
Subject: Re: [seam-dev] [seam-persistence]
ManagedPersistenceContextExtension
To: "Mark Struberg" <struberg(a)yahoo.de>
Cc: seam-dev(a)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(a)lists.jboss.org
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev