13 Replies Latest reply on Jan 24, 2007 6:28 PM by Gavin King

    Conversations

    jk;l jkl; Expert

      Why might a conversation be starting up without any @Begin or @End anywhere in my code. Nowhere in pages.xml is there a begin-conversation tag either. Why do I see a cid request parameter when browsing my pages every now and then...

      What things apart from the two I mentioned above could potentially begin a conversation?

        • 1. Re: Conversations
          Michael Singer Newbie

          As far as I know every faces request is conversation scoped by default, so if you haven't configured other scopetypes...

          And @Begin and @End will start and end a longrunning conversation which can exist over multiple request-response cycles.

          See chapter for conversations in seam-reference...

          • 2. Re: Conversations
            Gavin King Master

            There is always a temporary conversation context. And this context spans redirects. Hence the cid parameter.

            • 3. Re: Conversations
              jk;l jkl; Expert

              Is there a way to disable that behavior? Is that what propagation="none" or "end" is for in the pages.xml?

              • 4. Re: Conversations
                Gavin King Master

                No, no really good way at present. I suppose I could probably add a setting in pages.xml to disable propagation of the temp conversation to a view id. Try adding a feature request to JIRA, but note that this is not a high priority for me right now.

                • 5. Re: Conversations
                  Vladimir Kovalyuk Apprentice

                  Is is possible to start a new conversation with @Begin and leave the current one untouched? As result there will be two sibling conversations.

                  • 6. Re: Conversations
                    Gavin King Master

                    no.

                    • 7. Re: Conversations
                      jk;l jkl; Expert

                      I use a conversation-scope entity component as the value of a @DataModelSelection. Every time I select a row from the dataTable, the cid keeps incrementing! I do see why this is happening, but I'd like it not to...how would I get around this?

                      I tried changing the scope of the entity to EVENT and PAGE, but in both cases (while it stopped the incrementing cid) it made the value of the selected @DataModelSelection inaccessible...

                      In what scope should a @DataModelSelection entity be?

                      • 8. Re: Conversations
                        jk;l jkl; Expert

                        Additional question:

                        When updating elements in a long-running conversation, is one big update sent to the database when the conversation is explicitly ended?

                        Or are updates being sent to the database throughout the long-running conversation (i.e. every time a page gets submitted), but if the conversation is explicitly ended the transaction is committed and not rolled back?

                        • 9. Re: Conversations
                          Hung Tang Apprentice

                           

                          "lightbulb432" wrote:
                          Additional question:

                          When updating elements in a long-running conversation, is one big update sent to the database when the conversation is explicitly ended?

                          no.

                          Data is updated when a transaction starts and commits.
                          Read http://docs.jboss.com/seam/1.1GA/reference/en/html/configuration.html#d0e6392
                          use two transactions per request; the first spans the beginning of the update model values phase until the end of the invoke application phase; the second spans the render response phase


                          If you want one big update, specify @Begin(flushMode = MANUAL)

                          • 10. Re: Conversations
                            jk;l jkl; Expert

                            So if it's not sent as one big update, is it sent as I guessed in the second paragraph in my previous post?

                            If you specify flushMode=MANUAL, the docs say you explicitly have to call flush(). What happens if you end a conversation that has pending updates to it without calling flush()...aren't they flushed anyways??

                            When would you choose to use MANUAL vs not? Aren't both options really the same (i.e. intermediate updates held in database uncommitted vs in the session bean)?

                            I'm really confused.

                            • 11. Re: Conversations
                              Gavin King Master

                              This is basic Hibernate. The FlushMode controls when changes are sync'd to the database, and if you look at the documentation on the FlushMode class, you will see a precise definition of each mode. By default, all changes are flushed before the end of a transaction, which usually means that they are flushed in each request.

                              If you end a FlushMode.MANUAL conversation without explicitly flushing the persistence context then yes, of course the changes are lost. This is useful.

                              • 12. Re: Conversations
                                jk;l jkl; Expert

                                Thanks, that description cleared that up.

                                Let's say you have a conversation with several methods (one method called per request) and I use FlushMode.COMMIT/AUTO. If the first few requests in the conversation access a NEVER or NOT_SUPPORTED action method, and the next request accesses a REQUIRES (or similar) action method, would the persistence context be flushed when that REQUIRES method successfully returns?

                                Or would changes be flushed after every request because of the fact that there's always a transaction?

                                use two transactions per request; the first spans the beginning of the update model values phase until the end of the invoke application phase; the second spans the render response phase


                                How do the transactions from the quote above relate to the transactions specified by the transaction attributes?

                                If somebody could please lay this all out for me that'd be wonderful...I've been reading the Seam and Hibernate sections on transactions, but now I just need to ask a human...

                                • 13. Re: Conversations
                                  Gavin King Master

                                   

                                  Let's say you have a conversation with several methods (one method called per request) and I use FlushMode.COMMIT/AUTO. If the first few requests in the conversation access a NEVER or NOT_SUPPORTED action method, and the next request accesses a REQUIRES (or similar) action method, would the persistence context be flushed when that REQUIRES method successfully returns?


                                  Yes.

                                  Or would changes be flushed after every request because of the fact that there's always a transaction?


                                  If there is no container transaction, or Seam-managed transaction, the changes will not be flushed.