concurrency-ee-spec
  1. concurrency-ee-spec
  2. CONCURRENCY_EE_SPEC-10

Remove the concept of context properties from ContextService

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Remove the concept of context properties that are specified in the application code. Most context properties will be vendor-specific, and using a model where applications hard code vendor specific context properties will lead to applications that are not portable. Instead, any properties that are needed can be handled in the configuration that the application server provides for a ContextService. If an application requires specific contexts, a ContextService instance should be created for it, and referred to via resource-refs deployment descriptor elements or annotations. This implies removal of the method declarations:
      Object createContextObject(Object instance,
      Class[] interfaces,
      Properties contextProperties)
      void setProperties(Object contextObject,
      Properties contextProperties)
      Properties getProperties(Object contextObject)

      the class javadoc comments:

      Context properties can be stored with the proxy instance. Custom property keys must not begin with "ctxsvc.".
      Context properties are to be used for controlling how various contextual information is retreived and applied to the thread. Although application components can store arbitrary property keys and values, it is not recommended. Java EE product providers may impose limits to the size of the keys and values.
      Context property keys and values must all be of type java.lang.String. Use of the put and putAll methods on the java.util.Hashtable superclass are discouraged.

      and the field:
      static String USE_PARENT_TRANSACTION

        Activity

        Hide
        anthony.lai added a comment -

        From Nathan:

        I was just discussing this with Fred, who pointed out (and managed to convince me) that since there doesn't seem to be much interest in standardizing any application-defined context properties other then useParentTransaction, that it's probably fine to just use java.util.Properties as currently written, so we are withdrawing the issue CONCURRENCY_EE_SPEC-10 that we raised for this.

        You did bring up an interesting point about the ContextService API currently having two different mechanisms for configuring context properties.
        contextService.createContextObject(instance, contextProperties, interface)
        vs
        contextService.setContextProperties(contextualObject, contextProperties)

        I'd prefer choosing one mechanism or the other for the API and not having both of them.
        The latter is more flexible (as it allows for reuse of a contextualized object with different properties) but also more complex in that context properties could change while contextual operations are running (I assume the expectation here is that the context properties as of the start of the contextual operation would continue to be honored for the duration of that operation, and subsequent contextual operations would pick up the updated properties).
        -------

        Thus closing issue for now.

        ContextService.setContextProperties() removed.

        Show
        anthony.lai added a comment - From Nathan: I was just discussing this with Fred, who pointed out (and managed to convince me) that since there doesn't seem to be much interest in standardizing any application-defined context properties other then useParentTransaction, that it's probably fine to just use java.util.Properties as currently written, so we are withdrawing the issue CONCURRENCY_EE_SPEC-10 that we raised for this. You did bring up an interesting point about the ContextService API currently having two different mechanisms for configuring context properties. contextService.createContextObject(instance, contextProperties, interface) vs contextService.setContextProperties(contextualObject, contextProperties) I'd prefer choosing one mechanism or the other for the API and not having both of them. The latter is more flexible (as it allows for reuse of a contextualized object with different properties) but also more complex in that context properties could change while contextual operations are running (I assume the expectation here is that the context properties as of the start of the contextual operation would continue to be honored for the duration of that operation, and subsequent contextual operations would pick up the updated properties). ------- Thus closing issue for now. ContextService.setContextProperties() removed.
        Hide
        anthony.lai added a comment -

        Comment from Nathan (from Fred's team):

        First - I agree this open issue (or any of the others) should not hold up progress of the JSR.

        I would, if possible, like to help with a resolution for it.

        I agree there is certainly value in an application being able to identify certain details about its intended usage of, or requirements for, a contextual operation. USE_PARENT_TRANSACTION from the existing JavaDoc is a perfect example - only the application would know whether it's valid from a business logic standpoint to run in a new or existing transaction. The administrator shouldn't need to be aware of these sort of details.

        That said, we don't want to encourage the proliferation of non-portable code in applications. We shouldn't need to standardize any particular mechanism for vendor-specific information to be supplied in application code, as vendors in any case already have the freedom to come up with their own extensions using any mechanisms they want (including but not limited to String name/value pairs with a vendor API like what's currently in the JavaDoc).

        If we can agree that it's not necessary to enforce a particular mechanism for vendor-specific extensions, and take that out of the picture, then we have an opportunity to make what we do standardize for portable apps more straightforward and user-friendly.

        For example, a simple true/false interface method like,
        boolean useParentTransaction();
        Or, as another example, (I'm not suggesting we need to add this - it's just an example)
        boolean isLongRunning();

        These could go on Identifiable or on another new class/interface that we create for the purpose of identifying application-provided task details.
        Such an interface could be used just like Identifiable and submitted to ManagedExecutorService or ManagedScheduledExecutorService as well as ContextService.
        Whatever the mechanism we choose, it will be most beneficial to our users if we can agree on and standardize as much as possible of what information we know or expect they'll want/need to provide. Otherwise this will be the cause of lots of non-portable apps.

        Show
        anthony.lai added a comment - Comment from Nathan (from Fred's team): First - I agree this open issue (or any of the others) should not hold up progress of the JSR. I would, if possible, like to help with a resolution for it. I agree there is certainly value in an application being able to identify certain details about its intended usage of, or requirements for, a contextual operation. USE_PARENT_TRANSACTION from the existing JavaDoc is a perfect example - only the application would know whether it's valid from a business logic standpoint to run in a new or existing transaction. The administrator shouldn't need to be aware of these sort of details. That said, we don't want to encourage the proliferation of non-portable code in applications. We shouldn't need to standardize any particular mechanism for vendor-specific information to be supplied in application code, as vendors in any case already have the freedom to come up with their own extensions using any mechanisms they want (including but not limited to String name/value pairs with a vendor API like what's currently in the JavaDoc). If we can agree that it's not necessary to enforce a particular mechanism for vendor-specific extensions, and take that out of the picture, then we have an opportunity to make what we do standardize for portable apps more straightforward and user-friendly. For example, a simple true/false interface method like, boolean useParentTransaction(); Or, as another example, (I'm not suggesting we need to add this - it's just an example) boolean isLongRunning(); These could go on Identifiable or on another new class/interface that we create for the purpose of identifying application-provided task details. Such an interface could be used just like Identifiable and submitted to ManagedExecutorService or ManagedScheduledExecutorService as well as ContextService. Whatever the mechanism we choose, it will be most beneficial to our users if we can agree on and standardize as much as possible of what information we know or expect they'll want/need to provide. Otherwise this will be the cause of lots of non-portable apps.
        Hide
        anthony.lai added a comment -

        Comment from Fred:

        Although I would still prefer that they be managed via res-refs, we agree that they should not be part of Context. If we can't agree on using resource refs, I'd be ok with your suggestion to pass as method parms to executor service methods directly.

        Show
        anthony.lai added a comment - Comment from Fred: Although I would still prefer that they be managed via res-refs, we agree that they should not be part of Context. If we can't agree on using resource refs, I'd be ok with your suggestion to pass as method parms to executor service methods directly.
        Hide
        anthony.lai added a comment -

        Comment from Andrew:

        There are two problems that Contexts set out to solve:

        • Capturing vendor specific context to be transported with the task being submitted.
        • Passing additional information to Managed*Service

        For the first case, static Contexts work fine, there are only so many possibilities.

        For the second, the properties are much more like JMS properties than a JMS Destination, they can indicate to a (perhaps vendor specific) service some expectation of quality of service: priority, etc, or where the task should (or should not) run. Even two targets and five priorities results in 7 possible contexts if you can wrap multiple times, 10 if you cannot. The resource-ref approach means that operational decisions could require administrative changes.

        I'm certainly not attached to them being modeled as Context, I would prefer they were passed into the executor service methods directly.

        Show
        anthony.lai added a comment - Comment from Andrew: There are two problems that Contexts set out to solve: Capturing vendor specific context to be transported with the task being submitted. Passing additional information to Managed*Service For the first case, static Contexts work fine, there are only so many possibilities. For the second, the properties are much more like JMS properties than a JMS Destination, they can indicate to a (perhaps vendor specific) service some expectation of quality of service: priority, etc, or where the task should (or should not) run. Even two targets and five priorities results in 7 possible contexts if you can wrap multiple times, 10 if you cannot. The resource-ref approach means that operational decisions could require administrative changes. I'm certainly not attached to them being modeled as Context, I would prefer they were passed into the executor service methods directly.

          People

          • Assignee:
            anthony.lai
            Reporter:
            anthony.lai
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: