Preventing Passivation of SFSBs

[glassfishrobot]

Stateful Session Beans can be passivated (and so often serialized) by the container to disk to save resources. This behavior can lead to problems with performance, scalability and even robustness of the application. A SFSB may contain non-serializable attributes which prevent a successful serialization and lead to runtime exceptions.

Proposal: introduction of @NotPassivable annotation (TODO: suggest better name) to prevent passivation of SFSB. SFSB denoted with this annotation should never be passivated and the methods ejbActivate and ejbPassivate never invoked. In an overload scenario the container is supposed to destroy the SFSB instances, instead of passivating them.

@Documented @Target(

{ElementType.METHOD, ElementType.TYPE}

) @Retention(RetentionPolicy.RUNTIME) public @interface NotPassivable { }

Affected Versions

[3.2]

[glassfishrobot]

Reported by abien

[glassfishrobot]

wolfc said: tt>@Target(METHOD)</tt doesn't make much sense to me.

How about:

**PassivationTimeout.java**@Documented
@Target(TYPE)
@Retention(RUNTIME)
public @interface PassivationTimeout {
   long value();

   TimeUnit unit() default TimeUnit.MINUTES;
}

In the likes of StatefulTimeout.

[glassfishrobot]

abien said:

tt>@Target(METHOD)</tt doesn't make much sense to me.

How about:

**PassivationTimeout.java**> @Documented
> @Target(TYPE)
> @Retention(RUNTIME)
> public @interface PassivationTimeout {
>    long value();
> 
>    TimeUnit unit() default TimeUnit.MINUTES;
> }
>

In the likes of StatefulTimeout.

It was a copy and paste error. Sorry for that. @Target(TYPE) is a lot better

[glassfishrobot]

mvatkina said: How does PassivationTimeout come into discussion of preventing the passivation?

[glassfishrobot]

wolfc said: http://docs.oracle.com/javaee/6/api/javax/ejb/StatefulTimeout.html#value%28%29

A value of -1 means the bean will never be passivated due to timeout.

[glassfishrobot]

mvatkina said: See http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2012-05/message/23 for further discussion.

I think though that NonPassivatable is better than DoNotPassivate...

[glassfishrobot]

agoncal said: Instead of creating a new annotation, why not reusing tt>@Stateful</tt. Either with just boolean passivatable

@Target(TYPE) @Retention(RUNTIME)
public @interface Stateful {
   String name() default "";
   String mappedName() default "";
   String description() default "";
   boolean passivatable() default true;
}

Or with a time out, -1 meaning never passivate

@Target(TYPE) @Retention(RUNTIME)
public @interface Stateful {
   String name() default "";
   String mappedName() default "";
   String description() default "";
   TimeUnit passivationTimeOut() default TimeUnit.MINUTES;
}

[glassfishrobot]

@ldemichiel said: I prefer this approach as well.

[glassfishrobot]

reza_rahman said: I think the separate annotation might be useful elsewhere down the line (such as passivation capable CDI beans), as is the passivation timeout.

[glassfishrobot]

jrbauer said: +1 for adding an attribute on the existing annotation.

[glassfishrobot]

mvatkina said: As the email discussion decided not to add a passivation timeout, I'm assuming that those who agree, agree to add passivatable to tt>@Stateful</tt

[glassfishrobot]

@ldemichiel said: Could we please call it something more English-like though? Maybe passivationCapable ??

[glassfishrobot]

mvatkina said: It's actually a perfect English word, though relates more to the corrosion process (which is still a state of the instance) than to computer science. But I'm interested to hear what others think.

[glassfishrobot]

reza_rahman said: Not sure if this is what you were looking for input on, but I think "passivation capable" is the existing terminology...

[glassfishrobot]

mvatkina said: Uh-oh... how would you describe the beans that should not be passivated? "Not passivation capable"? "Passivation non-capable"? It just sounds simpler - "non-passivatable"...

[glassfishrobot]

reza_rahman said: I am certain the terminology in the CDI 1.0 spec is "not passivation capable". I believe that terminology was borrowed from the EJB spec by Gavin, but I am not certain. It is certainly worth checking.

[glassfishrobot]

mvatkina said: Interesting. There are no 2 words "passivation capable" in the EJB spec, but googling for them brings a lot of references to the CDI spec or related pages. CDI also defines javax.enterprise.inject.spi.PassivationCapable which can be a good thing that the two names are closed, or can confuse the developers...

[glassfishrobot]

jlmonteiro said: +1 for a new annotation. And it seems more consistent with @Cachable in JPA 2. Both are behaviors.

[glassfishrobot]

jlmonteiro said: Regarding the naming @PassivationCapable(false) looks great for me.

[glassfishrobot]

jrbauer said: What package would a new annotation reside in? I agree with the idea of making this common metadata at some point, so I don't think we should add another EJB annotation ... and I don't think we should add a new common annotation without working it through other JSRs that be interested (CDI).

[glassfishrobot]

mvatkina said: See the new section "4.6.5Disabling Passivation of Stateful Session Beans" (and related references to the passivationCapable element) in the next version of the spec

[glassfishrobot]

Was assigned to mvatkina

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-56

[glassfishrobot]

Marked as fixed on Thursday, July 5th 2012, 1:55:09 pm