Mailing-List: contact users-help@deltaspike.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@deltaspike.apache.org
Message-ID: <DUB126-W735E5B09005CE4A1B0CBF9CF380@phx.gbl>
From: Xavier Dury <kalgon@hotmail.com>
To: "users@deltaspike.apache.org" <users@deltaspike.apache.org>
Subject: Some thoughts about EntityManagerResolver and EXTENDED
 PersistenceContext
Date: Mon, 4 Jul 2016 10:19:31 +0200
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
archived-at: Mon, 04 Jul 2016 08:19:41 -0000

Hi=2C=0A=
=0A=
I know that the EXTENDED PersistenceContext usage is not recommended by the=
 DeltaSpike team but I would like to have a discussion about it.=0A=
=0A=
I am currently developing a small-scale intranet application where our core=
-business entity model has a lot of levels which can be lazily expanded/col=
lapsed in the UI (written in JSF). In this case=2C I really like to be able=
 to use an EXTENDED PersistenceContext and not really care about eagerly lo=
ading all associations as=2C most of the time=2C deep levels won't even be =
expanded (the decision is left to the user to expand what is needed). And t=
his is the concept that made me like Seam when it was first released.=0A=
=0A=
Now=2C I have some concerns about the EntityManagerResolver:=0A=
=0A=
- As an EntityManagerResolver kinda "extracts" the EM from its owning @Stat=
eful bean=2C what guarantees do I have that this EM won't be used in concur=
rent (AJAX) requests? If I am not mistaken=2C all method calls on a @Statef=
ul bean must be synchronized/locked but as the EM is not thread-safe and wo=
n't be called in the context of a call on its owning SFSB=2C this could be =
problematic. (Since JPA 2.1=2C I've seen a synchronization attribute on @Pe=
rsistenceContext but it has nothing to do with concurrent synchronization.)=
=0A=
=0A=
- Correct me if I am wrong but the JEE spec does not (yet) define how an EM=
 that was "extracted" from its owning bean should behave.=0A=
=0A=
Therefore=2C wouldn't it be better to replace the EntityManagerResolver by =
some sort of EntityManagerHolder like this one:=0A=
=0A=
public interface EntityManagerHolder {=0A=
=A0=A0 =A0=0A=
=A0=A0=A0 <T> T executeCallback(EntityManagerCallback<T> callback)=3B=0A=
}=0A=
=0A=
public interface EntityManagerCallback<T> {=0A=
=0A=
=A0=A0=A0 T execute(EntityManager entityManager)=3B=0A=
}=0A=
=0A=
and have it implemented like this:=0A=
=0A=
@Stateful=0A=
@TransactionManagement(BEAN) // TXs should not be handled here=0A=
@ViewScoped // for example=0A=
public class MyEntityManagerHolder implements EntityManagerHolder {=0A=
=0A=
=A0=A0=A0 @PersistenceContext(type =3D EXTENDED)=0A=
=A0=A0 =A0private EntityManager entityManager=3B=0A=
=0A=
=A0=A0 =A0public <T> T executeCallback(EntityManagerCallback<T> callback) {=
=0A=
=A0=A0 =A0=A0=A0 =A0return callback.execute(this.entityManager)=3B=0A=
=A0=A0 =A0} =0A=
}=0A=
=0A=
Here=2C all calls on the EntityManager will happen inside a call on the SFS=
B which should guarantee that only one thread at a time may use the EM and =
it also circumvents the gap in the specification.=0A=
=0A=
What do you think? Is there something I forgot to take into account?=0A=
=0A=
Thanks=2C=0A=
=0A=
Regards=2C=0A=
=0A=
Xavier 		 	   		  =