This is causing serious problems for our application. I tried switching to EJB3Clustered to hopefully use the TreeCache, but for some reason it's still using SimpleStatefulCache.

javax.ejb.EJBNoSuchObjectException: Could not find Stateful bean: 3j001-gthwm3-eofzrkxj-1-eogs4rla-sb
 at org.jboss.ejb3.cache.simple.SimpleStatefulCache.get(SimpleStatefulCache.java:266)

I'm seeing this in conjunction with a session scoped bean...

Without knowing a thing about the internals of SFSB, Seam, etc... is it possible that any cache / expiration setting for the session scoped SFSB is SHORTER than it needs to be?

I'm not sure where this value is held, but if my session scoped SFSB is getting expired out of the SimpleStatefulCache after say 5 minutes, and yet I intend a session scoped SFSB to stay around the lifetime of an HttpSession (30 minutes)...

Does / should the SFSB stay around the entire time that Seam holds a reference to it == lifetime of the HttpSession, or can the SFSB get expired out from SimpleStatefulCache before Seam is done with it...?

Ryan

I asked the EJB3 forum. The default expiration on SFSB is 300 seconds.

There are custom JBoss annotations called @CacheConfig for both Simple and Tree caches which allow this to be customized on a per-bean basis.

This all may prompt some clarification in the Seam docs? My general notion of a SESSION scoped bean is that it is going to be around for the length of an HttpSession, period. This just isn't the case by default. Also, it seems to me that if people are using custom CONVERSATION timeouts greather than the 5 minute default, that they could run into the same situation where the timeout you're expecing from Seam/HttpSession is different than the timeout of the SFSB.

Maybe Seam could implement some kind of "keep alive" annotated method on an SFSB to prevent the SFSB from getting expired out before its time?

I'm not sure what the answer is across vendors, but I guess I'll try setting the @CacheConfig on every SESSION scoped bean to 1800 to match my HttpSession.

Ryan

OK.

Another idea: if there was a hook for Seam to set those in JBoss per component, Seam could keep those in-sync with whatever settings were in web.xml regarding conversation timeout and session timeout.

As we discussed, I can work around this for Session scoped SFSB's by using the JBoss specific @CacheInfo annotation, setting the timeout to be the same as an HttpSession.

But what about Application scoped SFSB's? We run into this same problem due to the aforementioned reasons in this thread.

An Application scoped SFSB should be viable for the lifetime of an application... but it isn't, and setting a ridiculously large timeout using @CacheInfo would only delay the problem. JBoss times these out like any other SFSB, throws an EJBNoSuchObjectException, and Seam can't recover.

Since EJBNoSuchObjectException is a standard ejb exception, is there a way that Seam could gracefully recover from this?

This all (this thread) seems to me to be quite critical to the promise of Seam -- my component instances should be around for the lifetime of the scope context specified.

Ryan