Why do I get "FileNotFoundException" with passivated Statefu

[marc.fleury]

Alan from London asks:" When I use my Stateful session beans I sometime get "FileNotFoundException" from the Persistence Manager, why?"

[pboddie]

>If you want to handle this specific error in code you can catch the java.rmi.NoSuchObjectException that it generates.

In which script would I catch this exception and what would be the appropriate action afterwards?

Ricardo

[marc.fleury]

arthurg answers:
"Alan,

I have seen this occur when a stateful session bean reaches its maximum life time. In Jboss, firstly, after a period of time, a stateful bean is passivated and serialized to disk. After that, if it is still not accessed after a period of time, the serialized file on disk is destroyed. When this occurs you cannot access the stateful session bean again. If you want to handle this specific error in code you can catch the java.rmi.NoSuchObjectException that it generates.

The lifetime of the bean is defined in the standardjboss.xml file under your conf directory in jboss. In the xml file look at the <container-configuration> element for "Standard Stateful SessionBean". Under there is a <cache-policy-conf> element, containing various settings for caching. If not sure exactly how it works, but the <max-bean-life> element relates to the period of inactivity after which the bean is removed from disk.

arthur."

Alan adds

"It was the first time I had used a stateful session bean in jboss and I assumed it was a configuration problem. Turns out the bean was not being passivated properly because I had made the properties private!!

Thanx for the help anyway."

BOTTOM LINE:
1- Make sure that your beans can properly be passivated (with serializable fields and non private)
2- be careful with long running clients, if the component is not used on the server, it will be removed according to your configuration

[pboddie]

I had a few problems with transaction rollbacks not working with stateful session beans, and I was referred to this thread...

> arthurg answers:
> "Alan,
>
> I have seen this occur when a stateful session bean
> reaches its maximum life time.

This shouldn't be within the lifespan of a very quick test program, though, should it?

> In Jboss, firstly, after a period of time, a
> stateful bean is passivated and serialized to disk.

Could this happen as a side-effect of a transaction rollback? (This was my original problem.)

[...]

> BOTTOM LINE:
> 1- Make sure that your beans can properly be
> passivated (with serializable fields and non
> private)

Is it going to work if I have a couple of "double" attributes in my class (which are private) and a "SessionContext" attribute (also private)?

I also added some set methods for the attributes, just to see if that helped, but I kept getting the same behaviour - the bean can't be accessed after the transaction is rolled back.

> 2- be careful with long running clients, if the
> component is not used on the server, it will be
> removed according to your configuration

Can I forcibly passivate the bean to see if persistence is really the problem?

Another thing I noticed was that doing setRollbackOnly on the context object didn't cause a transaction rollback unless the exception subsequently thrown was an EJBException. There's a Bank example that Sun provide which clearly doesn't do rollback "in the container" as a result of this behaviour, unless it isn't supposed to work that way.

I'm sure it's possible to manually save attributes during transaction phases (there is at least one example of this out there), but surely it's possible to get the container to do all the hard work? In other words, the container restores the state of the session bean to what it was before the transaction started.

Am I being too ambitious/optimistic?

[pboddie]

Well, I actually found some information about what is (and in this case isn't) supported in transactions with stateful session beans.

Effectively, I can't expect the state of my stateful bean to be rolled back - session beans take part in transactions, but they aren't "transactional". Therefore, when a rollback occurs, the attributes (members/instance variables) of my session beans won't revert back to the values that were present before the transaction started.

See http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0007&L=ejb-interest&D=0&P=77773 and http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind9911&L=ejb-interest&P=R9073 for details.

That said, the persistence problem is still present...

[rixc]

Hello,

&gt; BOTTOM LINE:
&gt; 1- Make sure that your beans can properly be passivated &gt; (with serializable fields and non private)

Does the EJB specification state the all fields in the beans must be public or is it a Jboss implementation.

Ricardo

[rixc]

>If you want to handle this specific error in code you can catch the java.rmi.NoSuchObjectException that it generates.

In which script would I catch this exception and what would be the appropriate action afterwards?

Ricardo