The parent does not get flushed. Verify the conversation is actually getting nested.
It is nested and it is flushing indeed. Is the only way around this to use more than one SMPC?
Is it possible that your update is cascading?
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?
Just a little question: why don't you start a new not nested parallel conversation?
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.
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?
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.
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.
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?
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.