deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From titou10 <>
Subject Re: Extended EntityManager
Date Sun, 19 Apr 2015 13:12:19 GMT
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.

>> Am 18.04.2015 um 13:34 schrieb titou10 <>:
>> 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 <>:
>>>> 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 is identical to DS JPA example.
>>>>> So, something very close from DS JPA page example.
>>>>> 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

View raw message