1 Reply Latest reply on Aug 22, 2007 3:01 AM by Tom Baeyens

    Environment and contexts

    mvaldes Novice


      We had an internal discussion this morning on the use of both env and wire fonctionalities as well as the relationships between

      We are convinced of the powerful capabilities of the Environment concept and specially the use of the application context to leverage multiple engines configurations.

      Guillaume also presented features related to wiring and the use of the WiringContext as well as object descriptors.

      However, we don't know yet how to leverage the block context and when is useful to have multiple contexts in an environment:

      - Block context is intended (i'm reading the javadoc) for transactions and user authentication, for instance.
      - Other contexts can be created in different situations: for actions, web-requests, web-sessions, web-applications, business processes...

      We do not see whether those use cases applies to PVM developers (the ones working on process languages implementations) or to users (people building their own application on top of the PVM) ? probably both...

      Relating to PVM developers use cases: i.e transactions, actions, user authentication is not clear for us whether the use of contexts is better than just add plain java code in the languages extentions implementations.

      For instance, when dealing with actions we could just use reflection to load a java class and call the execute method.
      For transactions, we could define inside the language Execution implementations how to handle them depending of whether we use the standard or the enterprise engine version.

      What are the main benefits of having multiple levels of contexts in an environment ? I thought that was the main difference between this framework and spring for instace ?

      Miguel Valdes

        • 1. Re: Environment and contexts
          Tom Baeyens Master


          we don't know yet how to leverage the block context

          Application context is static. The same objects are shared for all the threads and all the transactions. E.g. hibernate session factory.

          For a block context the objects that are created only live for the duration of the try-finally block. E.g. a session. Each new environment will have a new block context cache, but it will use the same set of descriptors. Typically, a try-finally environment block represents a transaction. So the block context gives you lazy creation of the resources and it remember to give you the same resource if you ask it twice in the same transaction. Just the behaviour as you want it for a hibernate session. And the same goes for all other transactional resources.

          These are some of the features that are given by the container in enterprise environments. E.g. A DataSource will give you the exact same connection if you ask it twice within the same transaction.

          let me know what questions are left