I understand your points but, it is not a problem, at least for us.
Le 2015-04-19 04:59, Mark Struberg a écrit :
Ah oki, I see. Didn’t catch that you store it away.
There are quite a few tricky parts in practice with that approach (been there,
done that..). Not ultimately problems but at least points you need to be aware
off.
The first one is the serialisation issue I talked about in my blog post already.
true. But not a problem for us, we use "session affinity routing" and no session/SFSB replication (too costly for the benefits it
provides). We also blocked AS passivation
The second one is that you must not touch the same EntityManager in parallel
requests. But as the ConversationContexts is basically just a fraction of the
Session (and gets stored in there), you will likely hit that.
E.g. imagine a sendRedirect call in the middle of request A. Purely calling
sendRedirect will _not_ finish the thread which contains request A. It might
still need to do some work, e.g. send a message, clean up stuff etc. The
problem now happens if your clients browser executes the redirect faster
(resulting in Request B) than you could finish Request A. And in that case your
app will blow up by accessing the same EM from 2 different threads.
For parallel access, you are talking here on parallel requests for ONE user within a Conversation (Most likely Ajax requests I
guess) that will perform database updates access in parallel...
Have you *ever* hit this situation? Also, who programs a "sendRedirect" in the middle of a method that then performs database access
..? Even so, this is pure theory, the chance are so tiny this happens...And If you think this *may* happen within one conversation,
then change the way redirects are send, or the way database is accessed in parallel in Ajax requests. not the way EM is used IMHO
Also your remark on "unfinished thread" is valid for ANY components/resources
held in ConversationScope, not just the EM, true?
You will most likely not hit this issue during testing but _only_ under high
load in production :(
We never never never hit that with many applications in production with this pattern, and strong performance/load/stress tests
before going to prod.
However, it is true that we never specifically stressed tons of Ajax/parallel/unfinished/redirect requests for ONE user in its
session that perform database updates/access.
In fact with have not even one use case like that...
LieGrue,
strub
Well, again, this pattern works perfectly well for us, we never had performance/integrity/parallel problems, it solves many other
small problems with the EM and IMHO it is the best way to migrate from Seam 2 and continue to use one the Seam 2 paradigm.
It's just an option for you to use...or not. Having choice is fun.
Denis
Am 18.04.2015 um 13:34 schrieb titou10 <[email protected]>:
Mark,
We keep the EM in the conversation scope, but we expose it at the request scope
A new EM is created only when there is no one currently in the conversation
scope, so we have the same EM for the duration of the conversation, short or
long:
It is very close to what Seam 2 did
@ConversationScoped
public class EntityManagerProducer {
=====> private transient EntityManager em;
@PersistenceUnit
private EntityManagerFactory emf;
@Produces
@RequestScoped
protected EntityManager creerEntityManager() {
======> if (em == null) {
======> em = emf.createEntityManager();
======> }
======> return this.em;
}
Le 2015-04-18 01:35, Mark Struberg a écrit :
But in your example only the bean ‚holding‘ the producer method is
@ConversationScoped. The EntityManager you create is only @RequestScoped (which
is good imo!), right? So the lifecycle of the EM will effectively be
1-per-prequest.
LieGrue,
strub
Am 17.04.2015 um 22:30 schrieb titou10 <[email protected]>:
I can't comment on the DS/JPA example, but that's why the solution we use keeps the EM instance in
a variable, variable held in the @ConversationScoped Bean that "contains" the producer
that "exposes" this EM in the @RequestScope
The EM is opened/closed only on conversation boundaries (short or long) , very
similar to what Seam 2 does (In CDI, Conversations length is not exactly the
same as in Seam Conversations)
Denis
Le 2015-04-17 16:05, Ludovic Pénet a écrit :
Thanks to everybody for your valuable adviced.
I ended with an @ApplicationScoped EntityManagerProducer, producing
@ViewAccessScoped ExtendedEntityManager.
ExtendedEntityManager is identical to DS JPA example.
So, something very close from DS JPA page example.
http://deltaspike.apache.org/documentation/jpa.html#_extended_persistence_contexts
In fact, I am still a bit puzzled by DS JPA example, because the EntityManager
it produces is @RequestScoped.
So, when I basically copied/pasted it, the EM was just opened and closed on
every request. And, for an example, session was closed when some hibernate
proxies were accessed during serialization...
Do I miss something obvious, or should the doc rather mention that one should
use a scope such as @ViewScoped, @SessionScoped or @ViewAccessScoped rather
than @RequestScoped ?
Ludovic
