Sorry, forget to mention: The only pattern which _really_ works with JPA is entitymanager-per-request: em.close() at latest at the end of each request and em.merge() on demand in the postback.
LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Tuesday, April 17, 2012 6:53 PM > Subject: Re: wicket-cdi > >>> That's similar to storing the EntityManager in Conversations or > the >> Session - just broken and completely unusable in real world apps where you > have >> multiple cluster nodes... >> >> funny. thats exactly what we do, store EntityManager in conversations. >> no problems here. >> >> so i would say that, while the model can certainly be improved, i do >> not think it is broken. > > Well, here it goes: > > 1.) The EntityManager can only be accessed by one thread. If you access it > from > multiple threads it will complain via an ugly Exception. The reason for this > behaviour is the CAP theorem, Brewer. > > > 2.) The Conversation can also only be accessed by a single thread. But in > reality if you have a page with multiple AJAX components you will somewhen > get > concurrent requests. Another such situation appears if you do a redirect to a > new page which accesses this Conversation. If you have some post-processing > in > your request, like backup the session data to a memcached, the first request > still runs while the new (the redirection target) hits your application -> > wooom, crash. If you have a quick client you don't even need a memcached > handling but can reproduce this without if you stress your server a bit. > > Again: this works fine if you do just some clicky clicky, but once you do > heavy > load testing your whole app might blow up. > > > 3.) The EntityManager is NOT Serializable, but objects which get stored in > the > Session MUST be Serializable! This is defined in the Servlet spec. Otherwise > Session passivation, clustering, app restart etc will NOT work. Oh yes, I > know > that the Hibernate guys claim that their EntityManager is Serializable, but > thats just plain wrong. IF you Serialize a Hibernate EntityManager then you > will > loose ALL your entity states! You also need to explicitly enable this > 'feature' and loose a few other goodies. E.g the capability to run > correct queries if you have dirty entities in your local EntityManager, etc. > In > other words: this is really dangerous! That this also cannot work if you use > most of the LockModes via EntityManager#lock or EM#find(T, id, LockMode) is > obvious. > > Please read the last few paragraphs in the Hibernate clustering guide and you > will see what I mean. > > > LieGrue, > strub > > > ----- Original Message ----- >> From: Igor Vaynberg <[email protected]> >> To: [email protected]; Mark Struberg <[email protected]> >> Cc: >> Sent: Tuesday, April 17, 2012 6:37 PM >> Subject: Re: wicket-cdi >> >> On Tue, Apr 17, 2012 at 9:19 AM, Mark Struberg <[email protected]> > wrote: >>> Hi Igor! >>> >>> The Conversation behaviour is not defined at all for all the cases you > >> mentioned. It is really purely only defined in faces requests! >>> >>> The behaviour in ALL other cases, including non-faces Servlet requests > or >> Wicket requests is NOT defined at all. >> >> i meant contracts on the Conversation interface, etc. >> >>> For a Wicket app it would just make no sense at all to use the same > context >> control as a JSF application. Instead you should create and define your own > >> behaviour which works best for wicket applications. The trick with the CDI >> Extension to redefine @ConversationScoped beans to > @WicketConversationScoped >> beans is only for making it possible to re-use already existing >> @ConversationScoped beans. >> >> you have to define a "wicket" application first. it is very rare > for a >> large-ish application to use purely wicket. most applications end up >> using servlets for things like jaxb, rmi, etc. so we have to support >> not only wicket, but servlets as well. >> >>> Though I doubt that you will find many in real world projects... >>> >>> The CDI Conversation concept is imo seriously flawed and most people I > know >> tried it but dumped it pretty quickly. You can take a look at CODI > Conversations >> for example. There you will also find a list of issues with the current CDI > >> Conversations. >> >> we use it on a very large project and love it. we have a lot of >> complex ui workflows which wouldve been very clunky to implement >> without conversational scope. see >> > https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/ >> >>> Again: this stuff looks cool if you read through the paper, but with > big >> real world projects you pretty quickly hit a few problems. >> >> sure. weve hit a few problems, but nothing that was insurmountable. >> that is true with any non-trivial tech. >> >>> That's similar to storing the EntityManager in Conversations or > the >> Session - just broken and completely unusable in real world apps where you > have >> multiple cluster nodes... >> >> funny. thats exactly what we do, store EntityManager in conversations. >> no problems here. >> >> so i would say that, while the model can certainly be improved, i do >> not think it is broken. >> >> -igor >> >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> ----- Original Message ----- >>>> From: Igor Vaynberg <[email protected]> >>>> To: [email protected]; Mark Struberg <[email protected]> >>>> Cc: >>>> Sent: Tuesday, April 17, 2012 5:32 PM >>>> Subject: Re: wicket-cdi >>>> >>>> what about applications that share conversations between wicket > pages >>>> and servlets? having a wicket-specific conversation impl seems too >>>> narrow a usecase. why not just rebuild the conversation scope, > making >>>> it general, and controlled via a servletcontextlistener just like > weld >>>> does it...this should be portable and still work for > everything....and >>>> we can provide the SPI to control it. >>>> >>>> however, rebuilding such a thing in a way that works exactly how > the >>>> spec says would be no small fit. i am only for this if it can be >>>> removed cleanly and easily once cdi-1.1 is out. >>>> >>>> further, we have code that activates conversations in >>>> non-servlet-request threads. we use this to have a conversation > around >>>> background tasks. so this usecase, too, needs to be supported. >>>> >>>> -igor >>>> >>>> On Tue, Apr 17, 2012 at 4:10 AM, Mark Struberg >> <[email protected]> wrote: >>>>> Yes, this will get added to CDI-1.1. >>>>> >>>>> >>>>> But I personally expect CDI-1.1 only hit the street later > that >> year. The >>>> main reason for this is that CDI-1.0 is pretty well written and > usable >> already. >>>> Most of the changes are clarifications and wording corrections > which >> are >>>> perfectly possible to implement without changing the API. Most of > those >> changes >>>> already got implemented in the latest OWB and Weld versions. >>>>> >>>>> But things like the Context Control SPI changes are binary >> incompatible and >>>> can only be implemented later. >>>>> >>>>> By providing your very own Context you have it all under full > >> control. I >>>> can help with the impl if you need some help. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: Emond Papegaaij <[email protected]> >>>>>> To: [email protected] >>>>>> Cc: >>>>>> Sent: Tuesday, April 17, 2012 12:21 PM >>>>>> Subject: Re: wicket-cdi >>>>>> >>>>>> Ok, now I understand what you mean. Will it stay this > way, or >> are there >>>> plans >>>>>> to add the the conversation SPI to the spec? I think I > heard >> somewhere >>>> that >>>>>> they were planning to add those parts to the CDI spec, > making >> it >>>> possible to >>>>>> use the conversation scope in a portable way. In that > case, >> I'd >>>> rather leave >>>>>> >>>>>> it like it is now and move the to new SPI later on. > Writing a >> custom >>>>>> conversation scope for wicket seems like a lot of work > for >> something >>>> that >>>>>> already works fine with Seam. >>>>>> >>>>>> On Tuesday 17 April 2012 10:33:12 Mark Struberg wrote: >>>>>>> The seam-conversation stuff only works with one of > the n >> CDI >>>> containers: >>>>>>> Weld. >>>>>>> >>>>>>> >>>>>>> It will NOT work on Apache OpenWebBeans, Geronimo, > WAS, >> TomEE, etc >>>>>>> It will not even run on a few versions of GlassFish >> because they >>>> use a >>>>>>> different Weld version. >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>> > From: Emond Papegaaij >> <[email protected]> >>>>>>> > To: [email protected] >>>>>>> > Cc: >>>>>>> > Sent: Tuesday, April 17, 2012 11:21 AM >>>>>>> > Subject: Re: wicket-cdi >>>>>>> > >>>>>>> >T hanks for the feedback! It's good that > other >> people take >>>> a look >>>>>> at this >>>>>>> > >>>>>>> > code >>>>>>> > before we put it in Wicket. >>>>>>> > >>>>>>> > I don't understand the problem with >> @ConversationScoped. >>>> What do >>>>>> you mean >>>>>>> > with >>>>>>> > non-portable? Portable to what? AFAIK the >> conversation scope >>>> is part >>>>>> of >>>>>>> > the >>>>>>> > CDI spec and the current implementation in >> wicket-cdi works >>>> just fine, >>>>>> at >>>>>>> > least it does so for us. From what I understand > we >> use it the >>>> way it >>>>>>> > should be used. >>>>>>> > >>>>>>> > Best regards, >>>>>>> > Emond >>>>>>> > >>>>>>> > On Tuesday 17 April 2012 08:57:37 Mark Struberg > >> wrote: >>>>>>> >> A possible solution scenario: >>>>>>> >> >>>>>>> >> >>>>>>> >> a.) write an own @WicketConversationScoped > >> scope + >>>> Context >>>>>>> >> implementation >>>>>>> >> which especially fits wicket, supports > your >> browser tab >>>> handling, >>>>>>> >> conversation propagation etc. This will > fully >> portable >>>> and you >>>>>> have ALL >>>>>>> >> the >>>>>>> >> functionality fully in your own hands! >>>>>>> >> >>>>>>> >> >>>>>>> >> b.) write a small extension which uses the > >> @Observes >>>>>>> >> ProcessAnnotatedType. >>>>>>> >> In this Extension you can easily remove > all cdi >>>>>> @ConversationScoped >>>>>>> >> annotations and replace them via your very > own >>>>>> @WicketConversation at >>>>>>> >> container startup. Just modify the >> AnnotatedType as you >>>> need. >>>>>>> >> >>>>>>> >> The result is that a user can either use >>>>>> @WicketConversationScoped or >>>>>>> >> the >>>>>>> >> CDI @ConversationScoped but both will be >> handled as your >>>> own >>>>>> wicket >>>>>>> >> conversations. >>>>>>> >> >>>>>>> >> You might also implement your own pendant > to >>>>>>> >> javax.enterprise.context.Conversation > which is >> the >>>> interface to >>>>>> control >>>>>>> >> the >>>>>>> >> conversation lifecycle from within an >> application. I >>>> don't >>>>>> think that >>>>>>> > >>>>>>> > you >>>>>>> > >>>>>>> >> need to support the built-in Conversation >> control. The >>>> important >>>>>> point >>>>>>> >> is >>>>>>> >> imo that people can reuse components which > are >> annotated >>>> with >>>>>>> >> @ConversationScoped. For them it would > make no >>>> difference if the >>>>>>> >> non-working CDI conversation or your own > wicket >>>> conversation >>>>>> Context >>>>>>> >> implementation does the actual work > underneath. >>>>>>> >> >>>>>>> >> >>>>>>> >> LieGrue, >>>>>>> >> strub >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> ----- Original Message ----- >>>>>>> >> >>>>>>> >> > From: Mark Struberg >> <[email protected]> >>>>>>> >> > To: "[email protected]" >>>>>> <[email protected]> >>>>>>> >> > Cc: >>>>>>> >> > Sent: Tuesday, April 17, 2012 9:29 AM >>>>>>> >> > Subject: Re: wicket-cdi >>>>>>> >> > >>>>>>> >> > Whoops, clicked send to quickly ^^ >>>>>>> >> > >>>>>>> >> > s/ >>>>>>> >> > I try to get >>>>>>> >> > / >>>>>>> >> > >>>>>>> >> > I try to get a push request done > until the >> weekend. >>>>>>> >> > / >>>>>>> >> > >>>>>>> >> > LieGrue, >>>>>>> >> > strub >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > ----- Original Message ----- >>>>>>> >> > >>>>>>> >> >> From: Mark Struberg >> <[email protected]> >>>>>>> >> >> To: > "[email protected]" >>>>>>> > >>>>>>> > <[email protected]> >>>>>>> > >>>>>>> >> >> Cc: >>>>>>> >> >> Sent: Tuesday, April 17, 2012 > 9:18 AM >>>>>>> >> >> Subject: wicket-cdi >>>>>>> >> >> >>>>>>> >> >> Hi folks! >>>>>>> >> >> >>>>>>> >> >> I've quickly checked the >> wicket-cdi >>>> project on >>>>>> github and it >>>>>>> > >>>>>>> > looks like >>>>>>> > >>>>>>> >> > a >>>>>>> >> > >>>>>>> >> >> good start. >>>>>>> >> >> >>>>>>> >> >> I'd just change a few tiny > bits >>>>>>> >> >> >>>>>>> >> >> 1.) use > org.apache.geronimo.specs >> packages >>>> instead of >>>>>> javax.* >>>>>>> > >>>>>>> > packages >>>>>>> > >>>>>>> >> > because >>>>>>> >> > >>>>>>> >> >> of license reasons >>>>>>> >> >> >>>>>>> >> >> 2.) drop the CDI conversation >> support. To be >>>> honest (as >>>>>> a CDI EG >>>>>>> > >>>>>>> > member) >>>>>>> > >>>>>>> >> > The >>>>>>> >> > >>>>>>> >> >> built-in CDI Conversation is not > that >> useful >>>> as it has >>>>>> quite a >>>>>>> > >>>>>>> > few >>>>>>> > >>>>>>> >> >> flaws, >>>>>>> >> >> >>>>>>> >> > no >>>>>>> >> > >>>>>>> >> >> control api, etc. >>>>>>> >> >> >>>>>>> >> >> It might be better to introduce > an >> own >>>> portable >>>>>>> > >>>>>>> > WicketConversation which >>>>>>> > >>>>>>> >> >> supports the wicket browser-tab >> handling. >>>> Having a >>>>>> non-portable >>>>>>> >> >> >>>>>>> >> > conversation >>>>>>> >> > >>>>>>> >> >> support is imo a no-go. This > will >> most >>>> probably not >>>>>> even run on >>>>>>> > >>>>>>> > future >>>>>>> > >>>>>>> >> >> Weld >>>>>>> >> >> >>>>>>> >> >> containers... >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> 3.) Please add a profile for > Apache >>>> OpenWebBeans as >>>>>> well. Just to >>>>>>> > >>>>>>> > make >>>>>>> > >>>>>>> >> >> sure >>>>>>> >> >> >>>>>>> >> > your >>>>>>> >> > >>>>>>> >> >> project is really portable. >>>>>>> >> >> >>>>>>> >> >> I try to get >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> txs and LieGrue, >>>>>>> >> >> strub >>>>>> >>>> >> >
