Probably because the query is rerun every time you access the page versus if it is in the Session scope it won't be.

Yes, big time! I just switched over to sessions after spending several weeks trying to make natural conversations work. I'm now using sessions and I notice the pages (especially with a captcha) load in a blink of an eye whereas when using conversations you can actually see separate portions of the canvas being drawn.

In all honest I think the conversations feature in Seam is brittle and filled with too many bugs to be useful - certainly not able to withstand a deployed public server that is suppose to handle possibly hundreds of transactions per day. Also, in the last three weeks I've come across the following 'features' while using natural conversations:

• end-conversation elements in your pages.xml file does absolutely nothing. You have to revert to using the annotations which is fine but the documentation says you can use elements in your pages.xml.


• begin-conversation placed inside of a navigation element starts the conversation at the wrong time (I believe it creates new conversations if you use the browser back button). The begin conversation must be right at the beginning of the page element. this may be the expected way to use it but in the three paragraphs on natural conversations of the online user guide, it makes no mention of this sort of thing.


• intermittent duplicate conversation name errors at the startup of the server (Tomcat) where Seam somehow gets confused and insists that the pages.xml file contains two conversations with the same name. Shut down, make no changes, restart server and no error message (this happens about 20% of the time) so some sort of race condition exists? Dunno.


• if you use a(n) org.jboss.seam.faces.Renderer with a  natural conversation, you get the dreaded 'Conversation id is already in use'. Take out the call to the Renderer and no problems at all


• if the user clicks on the back button and clicks on a commandbutton of a previously closed/ended conversation (and they will do this), the app belches up in the log file about 'conversation id evaluated to null' and points the user to a debug page in the browser which, for a developer, is useful, but most definitely not what you want the user to be exposed to

I think what the Seam team needs to do now is put a freeze on any more features and create a dump load of examples using natural conversations. Seam bay is the only one in the examples (correct me if I'm wrong here) that uses natural conversations.

If they (the Seam developers) were to refactor most, if not all, of the examples to use natural conversations/nested conversations and everything you can do with the conversations, I think that they would uncover many of the problems users are having with Seam natural conversations.

Why the conversation scoped components with lists and no datamodel annotations have a performance problem?

What version of Seam?

Arron Ferguson wrote on Aug 29, 2008 04:51:


In all honest I think the conversations feature in Seam is brittle and filled with too many bugs to be useful -

Nonsense. You talk only about bugs in natural conversations.

certainly not able to withstand a deployed public server that is suppose to handle possibly hundreds of transactions per day. Also, in the last three weeks I've come across the following 'features' while using natural conversations:

• end-conversation elements in your pages.xml file does absolutely nothing. You have to revert to using the annotations which is fine but the documentation says you can use elements in your pages.xml.

Sounds like a bug, open a JIRA issue, include an example and steps to reproduce.

• begin-conversation placed inside of a navigation element starts the conversation at the wrong time (I believe it creates new conversations if you use the browser back button). The begin conversation must be right at the beginning of the page element. this may be the expected way to use it but in the three paragraphs on natural conversations of the online user guide, it makes no mention of this sort of thing.

Sounds wrong, but I would need to investigate. Open a JIRA issue with an example.

• intermittent duplicate conversation name errors at the startup of the server (Tomcat) where Seam somehow gets confused and insists that the pages.xml file contains two conversations with the same name. Shut down, make no changes, restart server and no error message (this happens about 20% of the time) so some sort of race condition exists? Dunno.

Possibly, again, a JIRA issue.

• if you use a(n) org.jboss.seam.faces.Renderer with a  natural conversation, you get the dreaded 'Conversation id is already in use'. Take out the call to the Renderer and no problems at all

Again, a JIRA issue.

• if the user clicks on the back button and clicks on a commandbutton of a previously closed/ended conversation (and they will do this), the app belches up in the log file about 'conversation id evaluated to null' and points the user to a debug page in the browser which, for a developer, is useful, but most definitely not what you want the user to be exposed to

Again, a JIRA issue.

In general, reporting issues which are clearly bugs in a concise fashion (which you have done) in JIRA will normally get you a lot further than moaning on the forum.

I think what the Seam team needs to do now is put a freeze on any more features and create a dump load of examples using natural conversations. Seam bay is the only one in the examples (correct me if I'm wrong here) that uses natural conversations.

Correct, they are a relatively new feature. Anyway, submit your patches to JIRA with these changes :-)

If they (the Seam developers) were to refactor most, if not all, of the examples to use natural conversations/nested conversations and everything you can do with the conversations, I think that they would uncover many of the problems users are having with Seam natural conversations.

Nested conversations are useful in some edge cases, natural conversations are more generally applicable, so we could have another example that uses them.

Yes, there is a real performance problem when using conversation scoped components that hold JPA/Hibernate entities.

If you don't need to support replication in a cluster and session passivation, then you can disable the interceptor that eats the most performance.
See Interception causes a huge performance penalty

IMHO this issue is not at all treated with the priority and prominence it calls for.
It affects some of Seam's biggest selling points and diminishes their usefulness to a great extent - conversations and entities as backing beans in particular and in general being enterprisey (supporting large applications, clustering, ... esp. compared to Ruby).

I mean, really, come on, many of my pages take a tenth of the processing time without this interceptor. If my user base would be so large that it required clustering, well, then I would need twenty machines in the cluster to be able to support twice the user base?