-
1. Re: Nested conversations using SMPC is stupid
gimpy21 Sep 22, 2009 9:18 PM (in response to pauljunk)The parent does not get flushed. Verify the conversation is actually getting nested.
-
2. Re: Nested conversations using SMPC is stupid
pauljunk Sep 22, 2009 10:47 PM (in response to 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 Sep 22, 2009 11:05 PM (in response to pauljunk)Is it possible that your update is cascading?
-
4. Re: Nested conversations using SMPC is stupid
pauljunk Sep 23, 2009 2:57 PM (in response to 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 Sep 23, 2009 3:44 PM (in response to 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?
-
6. Re: Nested conversations using SMPC is stupid
luxspes Sep 23, 2009 4:02 PM (in response to pauljunk)Just a little question: why don't you start a new not nested parallel conversation?
-
7. Re: Nested conversations using SMPC is stupid
pauljunk Sep 23, 2009 6:12 PM (in response to 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 Nov 26, 2009 12:46 PM (in response to pauljunk)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 Dec 1, 2009 11:42 PM (in response to pauljunk)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 Dec 1, 2009 11:46 PM (in response to pauljunk)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 Feb 1, 2010 11:56 PM (in response to 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 Feb 2, 2010 12:10 AM (in response to pauljunk)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.