I didn't test whether actual HA happened. I want HA to happen on this particular bean, so that solution doesn't work.
On Nov 19, 2013, at 6:48 PM, Marina Vatkina wrote:
> When passivationCapable = false the HA is not happening - see EJB 3.2 spec for the warning
>
> -marina
>
> On 11/19/13 11:06 AM, Lenny Primak wrote:
>> When using passivationCapable = false, the behavior is correct,
>> leading me to believe that this is a simple bug in glassfish vs. ejb spec issue
>>
>> On Nov 19, 2013, at 1:06 PM, Lenny Primak wrote:
>>
>>> Hi, EJB spec list:
>>>
>>> I have had a conversation with Marina about this, and she suggested I post of this mailing list:
>>>
>>> Basically, passivation mechanism has changed from Glassfish 3 to Glassfish 4 and now it has diverged
>>> from what I believe the spec and the documentation intended.
>>>
>>> Before, passivation (and @PrePassivate / @PostActivate) only happened when SFSB storage was running out
>>> and when the SFSB was about to be transferred from memory to storage and back again.
>>> This was the correct behavior.
>>>
>>> Since Glassfish 4.0, it appears that serialization is now used for this purpose. As a side effect of this (the erroneous behavior)
>>> is that every time Checkpointing method (i.e. pretty much every bean method invocation), it looks like
>>> SFSB is being passivated / activated. which is not what is supposed to happen according to the intent of the spec.
>>> Whats really bad is that not only the active resources are now being closed / reopened unnecessarily because of this,
>>> I no longer can have transient data in SFSBs with very limited workarounds available.
>>>
>>> Here is an EJB spec JIRA for this:
>>> https://java.net/jira/browse/EJB_SPEC-116
>>> Glassfish JIRA:
>>> https://java.net/jira/browse/GLASSFISH-20899
>>>
>>> Thanks for looking at this issue, I believe this breaks SFSBs to the point of being almost useless.
>>>
>>
>