Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2
    • Fix Version/s: Future version
    • Labels:
      None

      Description

      In EJB 3.1 the @Schedule annotation was introduced supporting cron style scheduled tasks. However, this annotation does not take in to account cloud based servers/multiple instances running. To support this idea, I believe we should add an attribute "perVM" or similar. Setting this to true states that this scheduled job should be run on all instances. Setting this to false should result in the scheduled job running in only one instance of the application.

        Activity

        Hide
        arjan tijms added a comment -

        See also JAVAEE_SPEC-5

        Show
        arjan tijms added a comment - See also JAVAEE_SPEC-5
        Hide
        marina vatkina added a comment -

        In which circumstances would a persistent timer need to run on all instances? Non-persistent timers always run on all instances, and it can be tricky to turn this behavior off.

        Show
        marina vatkina added a comment - In which circumstances would a persistent timer need to run on all instances? Non-persistent timers always run on all instances, and it can be tricky to turn this behavior off.
        Hide
        marina vatkina added a comment -

        Didn't get much traction in 3.2

        Show
        marina vatkina added a comment - Didn't get much traction in 3.2
        Hide
        kithouna added a comment -

        The important use case here is the ability to say a timer can only run on one instance in the entire cluster, but as soon as that instance is down another node should host the one and only active timer.

        Show
        kithouna added a comment - The important use case here is the ability to say a timer can only run on one instance in the entire cluster, but as soon as that instance is down another node should host the one and only active timer.
        Hide
        marina vatkina added a comment -

        This is already in the spec.

        In the event of a container crash or container shutdown, the timeout callback method for a persistent timer that has not been cancelled will be invoked on a new JVM when the container is restarted or on another JVM instance across which the container is distributed. This rule applies to both, programmatically or automatically created persistent timers.

        Show
        marina vatkina added a comment - This is already in the spec. In the event of a container crash or container shutdown, the timeout callback method for a persistent timer that has not been cancelled will be invoked on a new JVM when the container is restarted or on another JVM instance across which the container is distributed. This rule applies to both, programmatically or automatically created persistent timers.

          People

          • Assignee:
            marina vatkina
            Reporter:
            John D. Ament
          • Votes:
            5 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: