2 Replies Latest reply on Oct 15, 2007 4:08 PM by gavin.king

    Questions about SMPC, conversation and session scopes

    dkane

      Dear colleagues,

      I am implementing SMCP concept in multi-page DBMS application.
      Each page contains number of DataModels and CRUD operations.
      Logically, all data (entities) on all my pages should be scoped to session - all data grids and fields should save their state along the whole user's session. There are no cycles that could be considered as conversations.

      At the same time, SMCP is scoped to conversation. If I understand correctly, I have two options for this situation:

      1) Open global conversation on each page (and join if already opened), and scope all my components to ScopeType.CONVERSATION. This scope would be equal to session scope in fact, and SMCP will work.

      Question : Is it good practice ?


      2) Use session-scoped components (SFSBs by default).

      Questions :
      - should entityManager be injected with (scope=CONVERSATION) in this case ?
      - should dataModels and entity members be explicitly scoped by (scope=CONVERSATION) ?
      - when I create entity variable in method of session-scoped component, will it be correctly managed by conversation-scoped entityManager ("persist" operation, etc.) ?

        • 1. Re: Questions about SMPC, conversation and session scopes
          dkane

          These are fundamental things but I can't them clear from documentation, indeed.

          Please throw some light at least to the following.

          Entity beans are stated to have CONVERSATION scope by default.
          If managing component is scoped to SESSION, and CONVERSATION-scoped entities are fields of this component - what happens to them when conversation ends but session continues ?

          • 2. Re: Questions about SMPC, conversation and session scopes
            gavin.king

            Depends if they are @In fields or not.

            (1) If they are @In fields, they always refer to the entity in the current conversation
            (2) otherwise, they are just Java object references. Nothing "special" happens