On Tue, Apr 17, 2012 at 9:53 AM, Mark Struberg <[email protected]> wrote: >>> 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.
yes. but conversations have the same restriction. so no problem here. > 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. by the same thinking you can say that wicket is also broken for ajax requests because wicket serializes access to the page instance across requests, even ajax ones. so only one request can ever access a page at a time. not great for concurrency in theory, but in reality how many requests should a single user be able to make to the app? > Again: this works fine if you do just some clicky clicky, but once you do > heavy load testing your whole app might blow up. depends on how you do the testing. in realistic profiles you would have many users issuing requests at a slow pace. of course if you set it up so that many users issue requests quickly things may break, but thats not realistic testing. > > 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. to make this work we force flush mode to manual. so we have to code with that in mind - queries may return "stale" data - data that does not include changes made in the conversation. but, if you code with this in mind it is rarely a problem. -igor > > 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 >>>>>> >>>> >>
