-
1. Re: Conversations
mikepkp17 Jan 18, 2007 11:55 AM (in response to vk101)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 Jan 18, 2007 3:22 PM (in response to vk101)There is always a temporary conversation context. And this context spans redirects. Hence the cid parameter.
-
3. Re: Conversations
vk101 Jan 18, 2007 4:50 PM (in response to vk101)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 Jan 18, 2007 5:05 PM (in response to vk101)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 Jan 19, 2007 9:37 AM (in response to vk101)Is is possible to start a new conversation with @Begin and leave the current one untouched? As result there will be two sibling conversations.
-
-
7. Re: Conversations
vk101 Jan 22, 2007 1:48 AM (in response to vk101)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
vk101 Jan 24, 2007 11:40 AM (in response to vk101)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
hstang Jan 24, 2007 12:00 PM (in response to vk101)"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#d0e6392use 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
vk101 Jan 24, 2007 1:17 PM (in response to vk101)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 Jan 24, 2007 2:22 PM (in response to vk101)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
vk101 Jan 24, 2007 5:40 PM (in response to vk101)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 Jan 24, 2007 6:28 PM (in response to vk101)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.