I probably need to write another blog entry to properly address you questions. But here are some short answers: The key thing about Seam is that it offers “flexibility”. Seam does provide support for stateless components and eager loading of data. So, if that is what you decide best for your application, you can use it with Seam. However, what if you *also* want to lazy load some data? Seam helps you do it correctly and efficiently.

You are right that lazy loading requires more round trips to the database, but without lazy loading, you might end up loading a big chunk of your entire database in one entity object if you have a complex schema. So, the performances pros and cons are all relative, you have to judge it for your own application.

On the other hand, Seam’s stateful approach *reduces* database round trips by only flushing changes to the database at the end of each conversation. That is certainly useful if you read/write your DB a lot.

You also asked “What if my application is almost all read-only, yet highly personalized for the logged in user?”. Now how do you develop such apps in the past? Do you push all stateful data into HTTP session? Seam manages the exact same amount of stateful data. So there is no performance / scalability loss. On the contrary, since Seam guard against memory leaks associated with long life HTTP sessions, you have significantly lower risk for memory leak in such applications with Seam.

cheers
Michael

I don’t understand how SEAM can afford to maintain conversational state for thousands of concurrent users. If we are lazy-loading, how does a Conversation magically save me a round-trip to the database when traversing to a finer granularity? If the data was already out-of-the-database and held by the Conversation, then how can one still call that lazy-loading? Just because the web tier didn’t get it yet?

Where do we incur most of the expense? Getting data out of the table in the first place? Or the later transformation into something the web tier can use?

What if my application is almost all read-only, yet highly personalized for the logged in user? Virtually none of the information is shareable! immutable != shareable. Middle-tier caching now *hinders* my application, not help it.

By the way, the new release of Seam (due out this month) is optimized for use in an Ajax-based environment with many fine-grained, concurrent, asynchronous requests in the same session/conversation. In this kind of environment you absolutely *need* a stateful (and threadsafe) middle tier to avoid database traffic on every fine-grained request. (Traditional web application architectures not only suck at state management, they also suck at concurrency management.)

Yes I understand that there are many factors you need to evaluate when choosing an architecture. But performance should not be a problem here.

1. You can always run Ajax servlets in separate Tomcat servers, but at the same time, you can generate all dynamic web pages in a JBoss container. Of course, I am not familiar your architecture (e.g., I do not know how much caching / DB saving you need from Ajax servlets). So, maybe DTO is an okay trade-off in your situation.

2. “Modern” stateful architecture is is built on the same clustering technology as the HTTP session clustering. So, it should be at least as scalable as stateless + HTTP session.

1) we want to split physically the EJBs running in JBOSS and the Web app running in TOMCAT. Why? We have identified that AJAX applications increase dramatically the number of hits to the Servlet container (obvious) but most of these request returns Read Only data, hence easy cacheable to avoid unnecesary requests to the middlelayer and the database. So the ratio of JVM running TOMCAT and JVM running JBOSS can be 3 to 1 or 5 to 1 (in my projects, of course, this is not a rule of thumb). Also, we push the use of JMS as resource contention manager in the middle layer: web developers does not need to know about JMS inners.

2) Stateful architectures are not evil, but they are harder to scale than Stateless architecture. I’m not quite sure of this assertion nowadays, but I like to be conservative when building highly scalable architectures.

Please correct me if I’m wrong with some of my opinions.
Thank very much for your feedback.