Skip to main content

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

  • From: Anthony Lai < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties
  • Date: Tue, 13 Nov 2012 15:40:21 -0800
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

Hi Nathan,

Thanks for the suggestion.

Let's walk through the example in the ContextService javadoc. The example currently contains the following:

    public class MyServlet ... {
        ...

        // Get the ContextService that only propagates
        // security context.
        ContextService ctxSvc = (ContextService)
            ctx.lookup("java:comp/env/SecurityContext");

        // Set any custom context data.
        Properties ctxProps = new Properties();
        ctxProps.setProperty("vendor_a.security.tokenexpiration", "15000");

        ProcessMessage msgProcessor =
            ctxSvc.createContextObject(new MessageProcessor(), ctxProps,
            ProcessMessage.class);
        ...

    public class MyMDB ... {
        ...
        ContextService ctxSvc = (ContextService)
            ctx.lookup("java:comp/env/SecurityContext");
        Properties ctxProps = ctxSvc.getProperties(msgProcessor);
        ctxProps.setProperty(ContextService.USE_PARENT_TRANSACTION, "true");
        ctxSvc.setProperties(msgProcessor, ctxProps);
        // Process the message in the specified context.
        msgProcessor.processMessage(msg);
        ...

Suppose we remove properties from ContextService and create a new interface with the useParentTransaction() method. Let's call it TransactionContextHint for now.

The property "vendor_a.security.tokenexpiration" is vendor specific and is beyond the scope of the spec, so it would be taken out of this example.

To specify that the processMessage() method should be run within the transaction of the MDB, instead of setting the USE_PARENT_TRANSACTION property, the MessageProcessor would implement our new TransactionHints interface:
  
  public class MessageProcessor implements ProcessMessage, Serializable, TransactionContextHints {
      public void processMessage(Message msg) {
          // Process the message with the application container
          // context that sent the message.
          ...
      public boolean useParentTransaction() {
          return true;
      }
      ...

Is this inline with what you are suggesting?

Currently we only have one such property, useParentTransaction(). Should we have more in the future, say isLongRunning() as in your example, do you prefer they go to a different interface or do we use one interface for all these standard properties?

What about using new annotation type? We could modify MessageProcessor class in the example to something like this:

  public class MessageProcessor implements ProcessMessage, Serializable {
      @UseParentTransaction
      public void processMessage(Message msg) {
          // Process the message with the application container
          // context that sent the message.
          ...
This tells the container that the processMessage() method in the proxied object created by ContextService should be run under the parent transaction. Is this feasible? What do you think?

Regards
Anthony

On 11/5/12 1:33 PM, Nathan Rauh wrote:
" type="cite">Anthony,

I work on Fred's team, and was reviewing the draft, and noticed one of the issues we had raised was still open.
CONCURRENCY_EE_SPEC-10: Remove the concept of context properties from ContextService

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.

Hopefully this contributes towards a resolution rather than confusing things further.

I also noticed the following minor issue on the ContextService JavaDoc,
"All interface method invocations on a proxy instance run in the creator's context with the exception of hashCode, equals, and toString methods declared in java.lang.Object "
which is good because we wouldn't want those methods running with context.  Specifically mentioning only these three methods implies that other java.lang.Object methods (wait, notify, getClass, finalize, ...) should run with context, which I assume is not what we really want.  Would it make sense to update as follows?
"All interface method invocations on a proxy instance run in the creator's context with the exception of hashCode, equals, and toString  and all other methods declared in java.lang.Object "

Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802




From:        Anthony Lai ">< >
To:         ">
Date:        11/02/2012 03:46 PM
Subject:        [jsr236-spec users] [jsr236-experts] Early Draft for planned submission Nov 9




Dear experts,

I have posted an updated version of the early draft with only minor changes from the previous version:
  • Fixed usages of dependency injections in code examples throughout the document.
  • Clarified “optional” in optional contextual invocation points in section 2.3.1.1.
  • Added section for open issues.
  • Reduced levels of sub-sections in various Usage Example sections.
The document can be found at
http://java.net/projects/concurrency-ee-spec/downloads/download/EE%20Concurrency%20Utilities-Nov2.pdf

A version showing changes from the previous version can be found at

http://java.net/projects/concurrency-ee-spec/downloads/download/EE%20Concurrency%20Utilities-nov2-delta.pdf

No API changes were made this time. The javadoc zip file can be found at
http://java.net/projects/concurrency-ee-spec/downloads/download/javax.enterprise.concurrent-api-1.0-SNAPSHOT-javadoc.jar

We are planning to use this version of the document along with the javadoc zip file for submission to the JCP PMO office for Early Draft Review at the end of next week so that we can get feedback from the public and officially get the JSR out of inactive state. Please review the document so I could make any corrections before forwarding the draft to the PMO office.

We will continue to work on the spec to address any outstanding or new issues.

Regards
Anthony




[jsr236-spec users] [jsr236-experts] Early Draft for planned submission Nov 9

Anthony Lai 11/02/2012

[jsr236-spec users] [jsr236-experts] Re: Early Draft for planned submission Nov 9

Anthony Lai 11/09/2012

Message not available

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/13/2012

[jsr236-spec users] [jsr236-experts] Re: Re: issue 10: ContextService properties

Nathan Rauh 11/14/2012

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/15/2012

[jsr236-spec users] [jsr236-experts] Re: Re: issue 10: ContextService properties

Nathan Rauh 11/16/2012

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/16/2012

Message not available

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Nathan Rauh 11/19/2012

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/19/2012

Message not available

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/21/2012
 
 
Close
loading
Please Confirm
Close