12 Replies Latest reply on Feb 2, 2010 12:10 AM by asookazian

    Nested conversations using SMPC is stupid

    pauljunk

      How come when I flush a nested conversation that uses the same SMPC as its parent, the parent gets flushed as well. That's stupid. Seam is not managing the persistence context very well if you ask me.

        • 1. Re: Nested conversations using SMPC is stupid
          gimpy21

          The parent does not get flushed. Verify the conversation is actually getting nested.

          • 2. Re: Nested conversations using SMPC is stupid
            pauljunk

            It is nested and it is flushing indeed. Is the only way around this to use more than one SMPC?

            • 3. Re: Nested conversations using SMPC is stupid
              clerum

              Is it possible that your update is cascading?

              • 4. Re: Nested conversations using SMPC is stupid
                pauljunk

                The scenario is:


                I have a search page and when someone navigates to it I begin a new conversation with flush-mode - MANUAL.


                If a user chooses to edit a record from the search results, I then begin a nested conversation with flush-mode - MANUAL and navigate them to a new page. If the user enters invalid data into the form and and attempts to save it and it fails which is correct. The validation occurs in the invoke application phase so the entity is now in an invalid state but has not been flushed. The user then has the option of either fixing the invaid data or they can click the cancel button and that all works fine.


                The problem is that the user has an option on this edit record page to edit options given to them in a picklist. If they choose to edit these options then I navigate them to another page and I begin another nested conversation with flush-mode - MANUAL. When the user clicks the save button in this nested conversation, this flushes the data in the other nested conversation that is in an invalid state.



                I was thinking that maybe something didn't jive between the two nested convos so I tested to see if I made the first nested convo the parent and the second one the only nested convo and it still flushed the invalid data.



                I am using Seam 2.1.1GA. Possibly a bug or I don't have something configured correctly?

                • 5. Re: Nested conversations using SMPC is stupid
                  pauljunk

                  It looks like this issue has been an unresolved issue for the past couple of years. Anyone know if this is going to be addressed?


                  JIRA JBSEAM-1712




                  • 6. Re: Nested conversations using SMPC is stupid

                    Just a little question: why don't you start a new not nested parallel conversation?

                    • 7. Re: Nested conversations using SMPC is stupid
                      pauljunk

                      A parallel conversation produces the same results because it uses a conversation scoped SFSB that uses the same SMPC. Also, performing a clear in a nested conversation will not have desireable affects for the parent convo that use the same SMPC.



                      To me, it makes sense that you should be able to get away with writing an entire application only using a single SMPC and nested conversations to isolate flushing. The way that Seam sells nested conversations is that you can go off on a tangent and perform CRUD and then come back to where you left off but really you can only safely read data from nested conversations unless you use a separate entity manager for your nested conversations which is why I say Seam Managed Persistence Contexts are stupid and the only advantage to using them is that you can perform manual flushing when using JPA.






                      • 8. Re: Nested conversations using SMPC is stupid
                        yasudevil

                        Well, I suppose that SMPC is useful if you use the s:converEntity tag. Not sure if I still have to use that anyway.


                        So the solution for flushing something on a nested conversation that doesn't interfere with the objects in the root conversation is to configure another Entity Manager on components.xml?

                        • 9. Re: Nested conversations using SMPC is stupid
                          asookazian

                          I haven't used nested conversations in Seam extensively.  SMPC with Hibernate manual flush is very useful in many generic CRUD app cases.


                          One of the advantages is that with this combo you can avoid the LIEs b/c the PC stays open for the entire length of the LRC.  I'm sure it's more complicated when dealing with one (or more?) SMPCs and nested conversations.


                          Perhaps using parallel conversations like Francisco suggests is a good idea...


                          If the nested conversation is sharing the same SMPC as the parent (root) LRC, then that means when you flush() manually, then you will flush all queue operations (insert, update, delete) in the 1st level cache of the PC via write-behind/dirty-check, etc.


                          So if you want the parent to not be flushed, you need more than just one SMPC (i.e. one for parent and one for nested). 


                          Remember that the SMPC is conversation-scoped, it is an extended PC that is not tied to a particular tx or component.

                          • 10. Re: Nested conversations using SMPC is stupid
                            asookazian

                            And the key is that if the PC remains open for the duration of a LRC, then the entities remain managed (i.e. don't get detached until the persistence manager closes the PC at the end of the LRC).  As long as the entities remain managed, it's impossible for the LazyInitializationException (LIE) to occur.  LIEs occur when the entities become detached when the persistence manager closes the PC and there is object graph navigation in a JSF EL, for example.


                            One of the main selling points of Seam is this solution for the LIE problem which required workaround solutions in Spring/Hibernate like OSIV pattern.

                            • 11. Re: Nested conversations using SMPC is stupid
                              pauljunk

                              Has anyone found a more elegant solution to this problem other than having multiple SMPC's? Is there possibly a flag in the works that would only update changes made in the nested convo if a manual flush is performed there?

                              • 12. Re: Nested conversations using SMPC is stupid
                                asookazian

                                Below from question I asked in seam-dev mail list:



                                Are nested conversations removed in Weld/Seam3?

                                From CDI yes, from Seam3, not necessarily, but I suspect they may be redesigned.