ejb-spec
  1. ejb-spec
  2. EJB_SPEC-116

@PrePassivate / @PostActivate erroneously get called during checkpointing when Availability is enabled

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Invalid
    • Affects Version/s: 3.2
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      All

      Description

      I am trying to upgrade my software to GF 4.0, and I am running into this issue,

      Basically, the annotated methods get called on every method invocation when HA for
      the SFSB is enabled, Availability for the application is enabled, and availability-enabed in ejb-jar is set.

      Everything works correctly in GF3.1

      I always thought that these methods were only supposed to be called when SFSB
      was actually removed from memory and brought back into memory, i.e.
      SFSB pool runs out of storage.
      Method Checkpointing isn't supposed to be part of this as far as I know.

      Here is an excerpt from Oracle documentation:

      "
      You only need to use this annotation, along with its partner @PrePassivate, if you want to allow your stateful session bean to maintain the open resources that need to be closed prior to a bean instance's passivation and then reopened during the bean instance's activation.
      "

      So the new behavior doesn't make any sense to me.
      Also, it looks like the passivation and checkpointing mechanism has changed between GF 3.1 and 4.0 (for the worse)
      I don't think GF 3.1 used serialization, but GF 4.0 does, hence why this issue is coming up now.
      I think GF 3.1 used to restore state into an existing object, but now a new object is being created
      during checkpointing deserialization.

      Looks like here is the confusion: Passivation isn't checkpointing and @PrePassivate shouldn't have been called.
      Also, if all the application servers are doing it this way and it's wrong and doesn't match documentation this should be corrected? This behavior clearly doesn't match the documentation or even more importantly the intent of the Passivation mechanism.
      If Passivation happens, its intended for the object to be removed from memory.
      The intent is that Passivation callbacks don't happen unless the object is being removed from memory or brought back to memory.

      I posted in the Glassfish forum:
      https://www.java.net/forum/topic/glassfish/glassfish/gf4-sfsb-prepassivate-postactivate-get-called-every-bean-invocation-when-availability-enabled

      I also filed a Glassfish bug report for this:
      https://java.net/jira/browse/GLASSFISH-20899

        Activity

        Hide
        lprimak added a comment - - edited

        When using passivationCapable = false, the behavior is correct,
        leading me to believe that this is a simple bug vs. EJB spec issue

        @PostActivate gets called once upon SFSB creation and that's it

        This should behave exactly the same if passivationCapable = true

        Show
        lprimak added a comment - - edited When using passivationCapable = false, the behavior is correct, leading me to believe that this is a simple bug vs. EJB spec issue @PostActivate gets called once upon SFSB creation and that's it This should behave exactly the same if passivationCapable = true
        Hide
        lprimak added a comment - - edited

        Also, transient fields get lost on failover in GF 4.0:

        @Stateful
        public class MyBean implements Serializable
        {
        private String myState;
        private final transient Set<String> myTransient = new HashSet<>();
        }
        

        When HA-failover happens to a copy of MyBean on another cluster node,
        myTransient is null

        which is a regression from GF 3.1 and is how I found this error in the first place

        Show
        lprimak added a comment - - edited Also, transient fields get lost on failover in GF 4.0: @Stateful public class MyBean implements Serializable { private String myState; private final transient Set< String > myTransient = new HashSet<>(); } When HA-failover happens to a copy of MyBean on another cluster node, myTransient is null which is a regression from GF 3.1 and is how I found this error in the first place
        Hide
        marina vatkina added a comment -

        When passivationCapable = false the HA is not happening - see EJB 3.2 spec for the warning

        Show
        marina vatkina added a comment - When passivationCapable = false the HA is not happening - see EJB 3.2 spec for the warning
        Hide
        Carlo de Wolf added a comment -

        From a spec perspective I consider this issue "invalid".

        (No party-pooping intended )

        Show
        Carlo de Wolf added a comment - From a spec perspective I consider this issue "invalid". (No party-pooping intended )
        Hide
        lprimak added a comment -

        I would agree with this. This in my opinion is a simple bug in Glassfish, not a spec issue.

        Show
        lprimak added a comment - I would agree with this. This in my opinion is a simple bug in Glassfish, not a spec issue.

          People

          • Assignee:
            Carlo de Wolf
            Reporter:
            lprimak
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: