Serialzing while a transaction is open is going to give you problems no matter what. It
implies that the request has not finished yet, and the object may be being modified as it
is being written.
Also I am really not sure what you are talking about with case b), where in the spec does
it allow the EM to start a transaction on a query?
Stuart
On 11/07/2011, at 9:44 AM, Mark Struberg 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(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
>>
https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev