Conversations

[vk101]

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?

[mikepkp17]

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...

[gavin.king]

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

[vk101]

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

[gavin.king]

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.

[vladimir.kovalyuk]

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

[gavin.king]

no.

[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?

[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?

[hstang]

"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)

[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.

[gavin.king]

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.

[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...

[gavin.king]

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.