springframework-developer

[Springframework-developer] Passivating statefull session beans

[Tim M. <tec...@mo...>]

Hi,

I've just come across this and believe that some alterations may be 
needed to the AbstractSessionBean.

We are using JBoss 3.2.1.

When a stateful session bean is passivated in our code the following 
error appears:

12:11:39,611 WARN  [AbstractInstanceCache] failed to passivate, 
id=dnrbujgy-5
javax.ejb.EJBException: Could not passivate; failed to save state; 
CausedByExcep
tion is:
         org.springframework.beans.factory.xml.XmlBeanFactory
         at 
org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivate
Session(StatefulSessionFilePersistenceManager.java:378)
         at

We make a call to loadBeanFactory() in ejbCreate() but there does not 
seem a way to clear the bean factory upon passivation because it is 
private. It's easy to called loadBeanFactory() once again at 
ejbActivate() but by that time the damage is done and the bean has 
probably been removed by the server due to the passivation error.

Any chance you guys could look at this and maybe add in a fix for M4 or 
let me know a suitable work around.

Many thanks,

Tim

Re: [Springframework-developer] Passivating statefull session beans

[Colin S. <col...@ex...>]

I've modified the EJB support code to allow a user subclass of 
AbstractStatelessSessionBean to call a new method unloadBeanFactory() 
from ejbPassivate (which it should implement itself). The subclass 
should call the existing loadBeanFactory()  from ejbCreate() and 
ejbActivate().   As well, the default implementation of ejbRemove which 
is in AbstractEnterpriseBean now calls the new unloadBeanFactory() 
method.     There is one change that may affect some existing code, and 
that is that in the process of adding the above, I modified the existing 
BeanFactoryLoader interface to handle unloading as well as loading of a 
beanfactory.

These changes should allow you to use a Stateful Session bean properly 
even  wtih passivation and activation happening.

Regards,
Colin


Tim McAuley wrote:

> Hi,
>
> I've just come across this and believe that some alterations may be 
> needed to the AbstractSessionBean.
>
> We are using JBoss 3.2.1.
>
> When a stateful session bean is passivated in our code the following 
> error appears:
>
> 12:11:39,611 WARN  [AbstractInstanceCache] failed to passivate, 
> id=dnrbujgy-5
> javax.ejb.EJBException: Could not passivate; failed to save state; 
> CausedByExcep
> tion is:
>         org.springframework.beans.factory.xml.XmlBeanFactory
>         at 
> org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivate
> Session(StatefulSessionFilePersistenceManager.java:378)
>         at
>
> We make a call to loadBeanFactory() in ejbCreate() but there does not 
> seem a way to clear the bean factory upon passivation because it is 
> private. It's easy to called loadBeanFactory() once again at 
> ejbActivate() but by that time the damage is done and the bean has 
> probably been removed by the server due to the passivation error.
>
> Any chance you guys could look at this and maybe add in a fix for M4 
> or let me know a suitable work around.
>
> Many thanks,
>
> Tim

Re: [Springframework-developer] Passivating statefull session beans

[Tim M. <tec...@mo...>]

Colin Sampaleanu wrote:

> I've modified the EJB support code to allow a user subclass of 
> AbstractStatelessSessionBean to call a new method unloadBeanFactory() 
> from ejbPassivate (which it should implement itself). The subclass 
> should call the existing loadBeanFactory()  from ejbCreate() and 
> ejbActivate().   As well, the default implementation of ejbRemove which 
> is in AbstractEnterpriseBean now calls the new unloadBeanFactory() 
> method.     There is one change that may affect some existing code, and 
> that is that in the process of adding the above, I modified the existing 
> BeanFactoryLoader interface to handle unloading as well as loading of a 
> beanfactory.
> 
> These changes should allow you to use a Stateful Session bean properly 
> even  wtih passivation and activation happening.
> 
> Regards,
> Colin

Colin and others,

We've come across another issue to do with the passivation of beans. 
While our stateful session bean holds an instance of the bean factory 
itself (and can control re-initialising it), it is very possible that 
other standalone beans have a copy of the bean factory as well. If the 
stateful session bean has references to these other beans then it 
becomes very difficult to handle.

Is there any reason that the BeanFactory (and Loader) is not 
serializable. It would make it much easier to handle if they were.

Example of problem:

StatefulSessionBeanA HAS BusinessBeanB HAS BusinessBeanC HAD DAOBeanD

+ The Stateful Session bean will load the BeanFactory and lookup 
BusinessBeanB.
+ BusinessBeanB has the BeanFactory initialised through the 
ApplicationContext.xml file.
+ BusinessBeanB looks up BusinessBeanC using the BeanFactory.
+ BusinessBeanC initialising DAOBeanD through the ApplicationContext.xml 
file.

In this case, the stateful session bean has problems serializing 
BusinessBeanB due to the BeanFactory (XMLBeanFactory in this case).

Any thoughts?

Many thanks!

Tim

PS did you mean AbstractStatelessSessionBean or 
AbstractStatefulSessionBean above? Stateless beans are not 
passivated/activated.

Re: [Springframework-developer] Passivating statefull session beans

[Colin S. <col...@ex...>]

Tim McAuley wrote:

> Colin Sampaleanu wrote:
>
>> I've modified the EJB support code to allow a user subclass of 
>> AbstractStatelessSessionBean to call a new method unloadBeanFactory() 
>> from ejbPassivate (which it should implement itself). The subclass 
>> should call the existing loadBeanFactory()  from ejbCreate() and 
>> ejbActivate().   As well, the default implementation of ejbRemove 
>> which is in AbstractEnterpriseBean now calls the new 
>> unloadBeanFactory() method.     There is one change that may affect 
>> some existing code, and that is that in the process of adding the 
>> above, I modified the existing BeanFactoryLoader interface to handle 
>> unloading as well as loading of a beanfactory.
>>
>> These changes should allow you to use a Stateful Session bean 
>> properly even  wtih passivation and activation happening.
>>
>> Regards,
>> Colin
>
>
> Colin and others,
>
> We've come across another issue to do with the passivation of beans. 
> While our stateful session bean holds an instance of the bean factory 
> itself (and can control re-initialising it), it is very possible that 
> other standalone beans have a copy of the bean factory as well. If the 
> stateful session bean has references to these other beans then it 
> becomes very difficult to handle.
>
> Is there any reason that the BeanFactory (and Loader) is not 
> serializable. It would make it much easier to handle if they were.
>
> Example of problem:
>
> StatefulSessionBeanA HAS BusinessBeanB HAS BusinessBeanC HAD DAOBeanD
>
> + The Stateful Session bean will load the BeanFactory and lookup 
> BusinessBeanB.
> + BusinessBeanB has the BeanFactory initialised through the 
> ApplicationContext.xml file.
> + BusinessBeanB looks up BusinessBeanC using the BeanFactory.
> + BusinessBeanC initialising DAOBeanD through the 
> ApplicationContext.xml file.
>
> In this case, the stateful session bean has problems serializing 
> BusinessBeanB due to the BeanFactory (XMLBeanFactory in this case).
>
> Any thoughts?
>
> Many thanks!
>
> Tim
>
> PS did you mean AbstractStatelessSessionBean or 
> AbstractStatefulSessionBean above? Stateless beans are not 
> passivated/activated.
>
Of course I meant AbstractStatefulSessionBean, not Stateless...

W/regards to making BeanFactory serializable, Rod and Juergen would 
probably be able to best answer as to why it's not. I can't see much of 
a reason, to tell you the truth, so it's probably just historical. 
ApplicationContext (or most of its implementations rather) can not be 
serializable due to all the non-serializable classes used. So whether 
making BeanFactory serializable is useful to you depends on where you 
are actually using just a BeanFactory, with basic serializable beans in 
it, or are in fact using an ApplicationContext, with AOP, and things 
like interceptors and transaction managers inside it.

Regards,
Colin