In looking into why the testInVMSessionHandlePassivation was failing I see that the change to passivate in the invocation thread of control had the side affect of breaking the this testcase due to its use of a somewhat pathological "MaxOne Stateful Session" configuration that only allowed at most one active session. Because the testcase involved having one stateful session creat another, the original callee bean is forced out of the cache. This bean could not be passivated however, due to the outer call holding the session context lock.
The simplification to the cache is worth not supporting this type of silly configuration, but its possible that other bizzare configuration/cache policies might see similar behavior so I'm mentioning it. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
