Seam architecture advice on using EntityQuery and EntityHome

[gus888]

I have two architectures for using the EntityQuery and EntityHome. Anybody can give me advice which one is better for an enterprise application with large online users. Thanks a lot in advance.

Case A:
1) entity list (EntityQuery, event scope)
2) select entity:
    <s:link view="/entityView.seam" value="View">
        <f:param name="entityId" value="#{entity.id}"/>
    </s:link>
3) entity view (EntityHome, temporary conversation, page param entityId)
4) edit entity (EntityHome, long-running conversation)
5) entity view (EntityHome, temporary conversation, page param entityId)

Advantage: It only needs long-running conversation when editing entity. So it save system memory.
Disadvantage: Since it uses the page param of entityId, so it needs to retrieve entity data from database every time. Therefore, it needs lots database connections; second, if entityId is sensitive data, it is not safe, since users can change entityId from url, then press enter to retrieve other entity data.

Case B:
1) entity list (EntityQuery, event scope)
2) select entity:
    <h:commandLink value="View" action="#{entityHome.viewEntity}" immediate="true">
        <f:setPropertyActionListener value="#{entity}" target="#{entityHome.instance}"/>
    </h:commandLink>
3) entity view (EntityHome, long-running conversation)
4) edit entity (EntityHome, nested long-running conversation)
5) entity view (EntityHome, long-running conversation)

Advantage: It doesn't need to retrieve entity data every time when viewing a single entity. So it save database connection.
Disadvantage: It begins to use long-running conversation when viewing a single entity. So it uses more system memory than the first case.

[dan.j.allen]

My feeling is that option A is ideal if you want a RESTful application. Clearly, based on your comments, you want to prevent the RESTful case, which makes option B more attractive to begin with. Option B also has the benefit of reducing the number of queries that are run by maintaining the entity in the persistence context. So option B is clearly the winner for you.

Don't worry about conversations consuming memory. The whole reason they were introduced was so that you don't have to worry about them consuming too much memory. They are very short lived, and you can even make the conversation timeout for this particular scenario shorter (without affecting conversations across the application).

In the second case, the nested conversation isn't absolutely necessary.

[gus888]

Hi Dan,

Thank you very much for your reply. I really appreciate it. Could you please give me more help? I just got more understood what RESTful application is after viewing your reply.

For a web application with lots of simultaneous online users, e.g. a social network, which tech is better, RESTful or RPC? It seems that Case A looks like RESTful and Case B looks like RPC. Is it correct?

In addition, for a social network, which one is bottleneck, database connections or system memory?

Thanks a lot in advance.

Sheng